Request for comment: migrating from GTK2
Chris D
release in April 2011. PyGTK is now officially deprecated and
application are being migrated away from it.
The GNOME devs have released a porting guide. Porting to GTK3 however
is not straight forward, and will almost certainly introduce plenty of
GUI bugs that will require laborious testing and fixing. I am
therefore not all that keen on porting the existing GTK2 GUI of
AutoKey to GTK3. Instead, my preference is to resurrect the KDE/QT
version of AutoKey's GUI and bring that up to date. This would be far
less work for me than a GTK3 port.
I am conscious of the fact that many GNOME users will not like this
option as it means installing KDE dependencies just to run AutoKey.
There is a possibility of stripping out the KDE dependencies to make
AutoKey are pure QT application, which would reduce the dependencies.
Unfortunately this would also remove some of the rich features
provided by the KDE GUI libraries, but it might be an acceptable
compromise. I would have to investigate how much work this would
involve however.
Either way, this is a big decision so any comments or feedback would
be welcomed.
Chris D
long as this is feasible. This would come in the form of bug fixes,
and new back-end features where possible. However, new GUI features
would only be added to the KDE/QT version.
jos...@main.nc.us
I'm a KDE user, so that would be fine for me.
The current interface is very nice, but as long as the functionality
doesn't suffer too much, I don't really care what it looks like. After
all, it's a utility that I use to set things up. Once it's set up, I
don't look at it until I need to change something. I just use it
invisibly in the background.
Rewriting is a lot of work. Nokia bought Trolltech awhile back. It
appears that QT is alive and well in phone apps, so it should be available
for quite awhile. KDE is still used a lot, but is perhaps less certain.
So maybe depending on one major library instead of two would be a good
idea in the long run.
I certainly like KDE and plan to use it for as long as I can, so a KDE
version would be fine for me.
Since this is a gui application geared at end users anyway, I would think
that most users and the machines they run it on would not notice having
the KDE libraries present. It doesn't seem like a big deal. I use gedit
(and a few other gtk apps) occasionally and it works fine. The libraries
it needs are somewhere on my system. The only time I see it's not at home
is when I start it from a console and get a few warning messages while it
runs.
Joe
Chris D
is to make the GUI completely optional. This is much more feasible to
do now that AutoKey stores scripts and phrases as individual files. If
there was enough demand from minimalist users who don't want a GUI, I
could be persuaded to separate the engine from the GUI to make them
separately installable.
Johnny Rosenberg
I was just about to suggest a non GUI version. Editing text files
suits me fine, as long as it is reasonable straight forward. I took a
look at ~/.config/autokey/data and it didn't look too difficult.
Kind regards
Johnny Rosenberg
ジョニー・ローゼンバーグ
Al
Considering you are the primary coder on this project, I suggest you
do what you heart suggests that you do. Should the community ever grow
and people who can code are able to devote their time to you or the
project, then it would be feasible to consider forking into ports that
currently would cause excessive work. I for one would like to see
frequent updates vs prolonged updates, so I would rather you stay with
what you are comfortable. As to a non-gui version, I have no problems
with it either. Those of us who are geeky enough to install it are the
ones of us who are familiar with the command line and other editors.
So a non-gui version would be great and in my case since I am using
"lubuntu" on a 1ghz pc with 1gb of ram single core too eww I would
expect I might see a slight resource increase by doing so.
- Al
On Feb 23, 4:59 am, Johnny Rosenberg <gurus.knu...@gmail.com> wrote:
> 2012/2/23 Chris D <cdek...@gmail.com>:
Johnny Rosenberg
> Chris,
>
> Considering you are the primary coder on this project, I suggest you
> do what you heart suggests that you do. Should the community ever grow
> and people who can code are able to devote their time to you or the
> project, then it would be feasible to consider forking into ports that
> currently would cause excessive work. I for one would like to see
> frequent updates vs prolonged updates, so I would rather you stay with
> what you are comfortable. As to a non-gui version, I have no problems
> with it either. Those of us who are geeky enough to install it are the
> ones of us who are familiar with the command line and other editors.
> So a non-gui version would be great and in my case since I am using
> "lubuntu" on a 1ghz pc with 1gb of ram single core too eww I would
> expect I might see a slight resource increase by doing so.
>
> - Al
Maybe someone could make a script that guides you through the settings
with Zenity, for those who really don't want to enter text in a text
editor. Or maybe not.
Or maybe there could be some kind of AutoKey phrases doing most of the
typing job when creating a new phrase, for example, so the user only
needs to enter things like ”true”, ”false”, abbreviation, phrase etc.
On the other hand, it's not that difficult to copy an existing phrase
and turning it to a new one.
jos...@main.nc.us
Joe
jos...@main.nc.us
gui. But, take a look at yad. It picks up where zenity left off and is
being actively developed. The main developer is like Chris. He's very
involved with users and responsive to requests.
Joe
Johnny Rosenberg
> Just a note. zenity is cool. I have an application which uses it for its
> gui. But, take a look at yad. It picks up where zenity left off and is
> being actively developed. The main developer is like Chris. He's very
> involved with users and responsive to requests.
Thanks for the tip, I didn't know about Yad (and I still don't…). I'll
take a look at it!
I use Zenity for rather frequently, but I'm not doing very advanced
things at all, just some trivial bash scripts for doing small things.
There are a few things that I miss in Zenity, such as a dialogue for
entering time and other things that require an input mask. Maybe Yad
lacks that too, but I'll take a look at it. :)
Dutchguy
windows. Really love it but currently run a 0.7.1 because of the QT
version as I'm using KDE and do not want to bring in the dependencies
right now.
Would perfectly be happy without the gui as I currently manually
maintain the json file anyway. The lesser dependencies the better I
would say
Johnny Rosenberg
> I'm using autokey as text replacement similar to autohotkey in
> windows. Really love it but currently run a 0.7.1 because of the QT
> version as I'm using KDE and do not want to bring in the dependencies
> right now.
So why not run the 0.81.4 version of autokey-gtk? No KDE depencies, are there?
When I had Windows, about 200 years ago, or at least 5, I used
something called AllChars. It had the phrase thing but it also
simulated the Unix/Linux compose key function.
>
> Would perfectly be happy without the gui as I currently manually
> maintain the json file anyway. The lesser dependencies the better I
> would say
I agree, but I don't think that matters very much in Linux, more than
taking up more disk space.
jos...@main.nc.us
Does it really fill up your disk or memory, etc.?
I'm running AutoKey on kubuntu oneiric. I do use other gtk apps
anyway.(geeqie is one I'm particularly fond of.) I did notice some things
that didn't seem to work correctly until I installed a bunch of other
unrelated gtk things with their extended dependencies.
Joe
jos...@main.nc.us
based distro install, no GTK support is installed. Those are the
dependencies he's talking about and there are a bunch of them, some of
which apparently don't even get installed when you install autokey-gtk.
Joe
Johnny Rosenberg
> Out of curiosity, what impact would the gtk support have on your system?
> Does it really fill up your disk or memory, etc.?
>
> I'm running AutoKey on kubuntu oneiric. I do use other gtk apps
> anyway.(geeqie is one I'm particularly fond of.) I did notice some things
> that didn't seem to work correctly until I installed a bunch of other
> unrelated gtk things with their extended dependencies.
>
> Joe
>
thought you didn't want to bring in the KDE dependencies, but now I
can see that it was the other way around, obviously. So just ignore my
answer.
I still don't know what you meant, though. Why can't you use a more
recent version than 0.7.1 again? Do you have a too old version of KDE
or QT installed or what…?
Kind regards
Johnny Rosenberg
ジョニー・ローゼンバーグ
>> I'm using autokey as text replacement similar to autohotkey in
Johnny Rosenberg
> 2012/2/26 <jos...@main.nc.us>:
>> Out of curiosity, what impact would the gtk support have on your system?
>> Does it really fill up your disk or memory, etc.?
>>
>> I'm running AutoKey on kubuntu oneiric. I do use other gtk apps
>> anyway.(geeqie is one I'm particularly fond of.) I did notice some things
>> that didn't seem to work correctly until I installed a bunch of other
>> unrelated gtk things with their extended dependencies.
>>
>> Joe
>>
> Sorry, I was probably too tired when I read your post yesterday. I
> thought you didn't want to bring in the KDE dependencies, but now I
> can see that it was the other way around, obviously. So just ignore my
> answer.
> I still don't know what you meant, though. Why can't you use a more
> recent version than 0.7.1 again? Do you have a too old version of KDE
> or QT installed or what…?
>
>
> Kind regards
>
> Johnny Rosenberg
> ジョニー・ローゼンバーグ
>
And now I answered the wrong guy… Ok, the answer above was for
”Dutchguy”, as it seems…
Archie Arevalo
I am an RPM-based distro packager (and maybe not a very good one at that) and our distro is stuck with the 0.7.1 on its repository because I couldn't get the latest to build. And that's a good percentage of deprived potential AutoKey users.
I hope things can be better.
Peace and much respect,
Archie
Joon Ro
okular, kile, lyx, etc,
so for me it should be fine.
I always find myself using both gtk and qt based apps simultaneously.
Joon
Chris D
these days. I'd have to say that with the advent of QGtkStyle and
Oxygen-gtk either style of app will integrate well into either desktop
environment, so there is no real justification for a bias (unless you
have a truly tiny hard drive). Over the past weekend I've made much
progress in getting the KDE version up to date, so I will continue
working on that.
Archie - re RPM packaging - the next version will include an updated
rpmspec.
Chris
Archie Arevalo
Thank you, Christ.
Kevin
move. Given that QT4 is able to match the "native" widget style very
nicely, apparently without much effort, this should facilitate porting
the UI to other platforms at a point in the future. As I've mentioned
before, KeePassX is a prime example. Trolltech/Nokia have certainly
put a lot of effort into getting this right. Ported GTK apps look and
perform poorly by comparison; on OS X, in particular, GTK apps require
X11 and therefore do not use system standard modifier keys (i.e., Ctrl
instead of Cmd), do not integrate well with the native clipboard, and
do not use native file selectors (Save/Open)—GIMP being a prime
example here.
I haven't used KDE as a desktop environment since the 2.x days, and
yet I rely on a variety of KDE/QT apps that happily coexist in my
GNOME 2 environment. You're right; it's amazing how well they blend
in, provided that QGtkStyle is configured out of the box. No major
issues with Ubuntu 10.x. That QT apps don't work with the now
obsolescent 'gnome2-globalmenu' panel applet is something I've learned
to live with. Neither do Mozilla apps or LibreOffice. I suppose they
all work with the much-improved Unity global menu, I dunno.
KeePassX somehow even knows to use the desktop environment's
"native" (in my case, GTK) file selector, which I *much* prefer to the
default KDE one. Other KDE-native apps (e.g., Okular) don't do this,
so KeePassX is doing something special here and it may be instructive
to look at its code. A non-native file selector is usually one of my
biggest gripes about running applications which use "foreign"
toolkits.
Thanks again for all your efforts.
