24 Feb
2006
24 Feb
'06
9:02 p.m.
Hello all.
I've always steered clear of writing GUIs, so my experience is pretty
limited. But now I find myself needing a toolkit/widget set.
What's recommended? I'd prefer not to have to move my app from C to
C++ just to implement the interface, so that's quite a few out of the
window.
I don't really want huge dependencies for a knob, text box and a
button, either.
And something that's installed as default in most distros would be
good, too.
So, what I want is everything. And it should be simple, too.
Any suggestions?
James
--
"I'd crawl over an acre of 'Visual This++' and 'Integrated
Development
That' to get to gcc, Emacs, and gdb. Thank you."
(By Vance Petree, Virginia Power)
24 Feb
24 Feb
9:56 p.m.
james(a)dis-dot-dat.net wrote:
I'd prefer not to have to move my app from C to
C++ just to implement the interface, so that's quite a few out of the
window.
I'm sure that I dislike C++ even more than you do and I can completely
understand why you'd want to keep you app as C.
However, GUIs is actually one of the few applications where IMHO
C++ may actually have some benefits over C. It would definitely
be possible to do a C++ GUI which communicates with a C backend
but it would be necessay place a clothes peg over one's nose
while doing the C++ stuff.
That said, I have done GUIs in GTK+ (which is C) and it is doable,
especially if you spend some time wrapping the the GTK+ trivialities
into something more managable. So for instance, it you need 5 buttons
that are basically the same bar button names etc, instead of doing
button1 = gtk_new_button("button1 name") ;
gtk_fiddle_with (button1) ;
button2 = gtk_new_button("button1 name") ;
gtk_fiddle_with (button2) ;
...
button5 = gtk_new_button("button1 name") ;
gtk_fiddle_with (button5) ;
do something like:
struct button_s
{ const char * name ;
int xpos, ypos, xsize, ysize ;
} ;
static struct button_s deez_buttons [] =
{ { "button1_name", 0, 0, 20, 20 },
{ "button2_name", 0, 0, 20, 20 },
{ "button3_name", 0, 0, 20, 20 },
{ "button4_name", 0, 0, 20, 20 },
{ "button5_name", 0, 0, 20, 20 }
} ;
and then write a function that takes an array of button_s structs
and does whatever is required to make them happen.
I also like to have all button messages pass back through one
callback. Each button will have a unique identifier so that in
the callback I can just switch on the button identifier.
This can easily be extended to have all GUI callbacks passing
through the one callback function and them make the whole thing
a model controller view thing.
I don't really want huge dependencies for a knob,
text box and a
button, either.
Most GUI widget toolkits have a huge set of dependancies regardless :-).
GTK+ is no different in this regard.
And something that's installed as default in most
distros would be
good, too.
GTK+ is shipped with most distros.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Perl as a language has less a design than a thousand special features
flying in close formation."
-- From the c2 wiki
10:02 p.m.
On Sat, 2006-02-25 at 01:14 +0000, james(a)dis-dot-dat.net wrote:
I've always steered clear of writing GUIs, so my
experience is pretty
limited. But now I find myself needing a toolkit/widget set.
What's recommended? I'd prefer not to have to move my app from C to
C++ just to implement the interface, so that's quite a few out of the
window.
I don't really want huge dependencies for a knob, text box and a
button, either.
And something that's installed as default in most distros would be
good, too.
So, what I want is everything. And it should be simple, too.
For simplicity, try Gtk+ with libglade and build the GUI in Glade2.
Personally I think gtkmm is a lot nicer, but if you don't like C++ you
probably won't agree.
--
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
25 Feb
25 Feb
1 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
On 2/25/06, james(a)dis-dot-dat.net <james(a)dis-dot-dat.net> wrote:
Hello all.
I've always steered clear of writing GUIs, so my experience is pretty
limited. But now I find myself needing a toolkit/widget set.
What's recommended? I'd prefer not to have to move my app from C to
C++ just to implement the interface, so that's quite a few out of the
window.
I don't really want huge dependencies for a knob, text box and a
button, either.
And something that's installed as default in most distros would be
good, too.
So, what I want is everything. And it should be simple, too.
Any suggestions?
James
--
"I'd crawl over an acre of 'Visual This++' and 'Integrated
Development
That' to get to gcc, Emacs, and gdb. Thank you."
(By Vance Petree, Virginia Power)
You can check out smack's very simple former gui (still in svn but
disabled) or any dssi gui many are written in gtk and are nice
examples to learn from. In smack's gui i create a grouping widget so i
don't have to cope with cruft for each extra row of buttons.
Loki
7:39 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
Personally, I'd love to see more GTK2 apps around.
I think it's the oldest *full featured* toolkit around and I think even
the bloat is bearable (just keep your hands off anything that says 'Gnome')
Carlo
8 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sat, 2006-02-25 at 12:39 +0100, Carlo Capocasa wrote:
Personally, I'd love to see more GTK2 apps
around.
I think it's the oldest *full featured* toolkit around and I think even
the bloat is bearable (just keep your hands off anything that says 'Gnome')
/me starts a flamewar
Even the packages which say gnome-vfs? So you _want_ the applications to
be incapable of loading & saving files over smb shares, ftp shares,
webdav or ssh shares? How about future proof sharing models? VFS handles
that too. Oh, and how about printing?
Like it's been said before. Installing kde or gnome libraries, doesn't
force you to use either desktop environment. The libraries do take some
disk space, but I personally think the benefits derived from using the
libraries outweigh the disk space taken.
I'm a programmer = I'm lazy = I don't want to write printing dialogs, or
VFS support, especially since it's already provided by gnome.
Bottom line, as I see it is: look at what features gnome / kde offers
you. If they offer something you need (like VFS or printing) you SHOULD
use them. Your own printing dialogs or VFS support will be inferior to
what the gnome / kde teams come up with. Why? It's their job. An audio
software programmer's job is to make the AUDIO part work really well,
not use their time reimplementing the wheel.
(Having said this, Ardour will probably never have gnome dependencies
because afaik at the moment gnome doesn't offer us anything we need).
--
Sampo Savolainen <v2(a)iki.fi>
8:15 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
I'm a programmer = I'm lazy = I don't want
to write printing dialogs, or
VFS support, especially since it's already provided by gnome.
Heh, I'm only a novice programmer, and I'm already lazy :)
I think widgets are a GOOD thing. I also think modularity is a good thing.
KDE and Gnome both appear greedy to me. They both want me to use their
system and hence, tell me how to use my computer. Very little care is
taken to make sure individual parts can be used without installing the
whole whack. It's like I want to marry the girl I love but I can't
without also marrying her cousin, her sister and her aunt. This is the
Win/Mac philosophy, not the UNIX philosophy, and especially not the free
software philosophy.
That is why I recommend XFCE which does exactly that.
Carlo
10:56 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sat, 2006-02-25 at 13:15 +0100, Carlo Capocasa wrote:
Heh, I'm only a novice programmer, and I'm
already lazy :)
Ah, the sign of a good programmer. :)
KDE and Gnome both appear greedy to me. They both want
me to use their
system and hence, tell me how to use my computer. Very little care is
taken to make sure individual parts can be used without installing the
whole whack. It's like I want to marry the girl I love but I can't
without also marrying her cousin, her sister and her aunt. This is the
Win/Mac philosophy, not the UNIX philosophy, and especially not the free
software philosophy.
It's true that with KDE you are marrying into KDE's family with bastard
cousins like ksycoca, kdeinit, klauncher etc. But this isn't true with
gnome.
That is why I recommend XFCE which does exactly that.
Does xfce provide nice printing tools? How about VFS?
These two are the things I would _never_ want to implement: Extending a
file selector to provide support for remote protocols and filling
landfills/recycling plants with print dialog tests. argh. Of course,
it's a matter of whether you really need the sorts of widgets etc. that
these packages provide.
I'd rather give the users tried, tested & proved concepts which are well
supported and developed onwards by people who really want to develop the
sort of software it is. This would leave me to concentrate my efforts on
what the application is really supposed to do.
Of course, we are free to do whatever we want. I just don't see real
downsides to gnome integration.
I love the UNIX philosophy, but it doesn't mean zero integration.
Free software philosophy doesn't have anything against integration
either; How would it be "free" if you couldn't use the (free) libraries
you want? ;)
--
Sampo Savolainen <v2(a)iki.fi>
12:55 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
Ah, the sign of a good programmer. :)
There are actually people who still count, when
for (int i=0;i<n;i++)
cout << i << endl;
is in itself a work of pristine beauty, immense practicality, and you
can spend a lot of time lying around while the machine approaches n.
The world is full of mysteries.
It's true that with KDE you are marrying into
KDE's family with bastard
cousins like ksycoca, kdeinit, klauncher etc. But this isn't true with
gnome.
Well I'm not kissing gnomecanvas.
>That is why I recommend XFCE which does exactly
that.
Does xfce provide nice printing tools? How about VFS?
Printing? No idea. Haven't used any paper for ages. As for VFS IMHO
that's not the job of a desktop environment but of something mountable,
which can be accessed by XFFM, Nautilus, Konqueror and the Midnight
Commander alike. Where are the text-based frontends for KDE print
dialogs? We've got to have a little more flexibility and client server,
we're Unix!
These two are the things I would _never_ want to
implement: Extending a
file selector to provide support for remote protocols and filling
landfills/recycling plants with print dialog tests. argh. Of course,
it's a matter of whether you really need the sorts of widgets etc. that
these packages provide.
I agree that it is nice to have lot's of specialized APIs around. I also
believe they should be cult-free. Branding has done enough harm in the
commercial world.
I'd rather give the users tried, tested &
proved concepts which are well
supported and developed onwards by people who really want to develop the
sort of software it is. This would leave me to concentrate my efforts on
what the application is really supposed to do.
I absolutely, whole-heartedly agree. I simply believe all those things
should be implemented in a cross-desktop manner so whoever feels like it
can run a frontend. If the same were true for file compression we'd have
seperate implementations of gzip for KDE, Gnome and Fluxbox, all of
which would be buggy and partly incompatible. That's obviously silly. We
need dedicated people to implement things ONCE and then have a bunch of
artists who can make consistent front-ends if they feel like it.
Back-end must be untied.
Of course, we are free to do whatever we want. I just
don't see real
downsides to gnome integration.
As for frontends, sure! Backends must be desktop-independant or we have
Windowsware.
By the way, I'm really enjoying talking to intelligent people about
interesting subjects. I've been making some efforts to dumb myself down
a little recently in order to get a glimpse of the Sitcom-Loving world
but it's been like walking around with a chain ball on my anchle. This
is very refreshing.
Carlo
6:54 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
Carlo Capocasa wrote:
Shouldn't you put parentheses around on or the other of those
left shift operators? :-)
Ah, the sign of a good programmer. :)
There are actually people who still count, when
for (int i=0;i<n;i++)
cout << i << endl; is in itself a work of pristine beauty, immense
practicality, and you
can spend a lot of time lying around while the machine approaches n.
If you want pristine beauty, you should have a look the function
to find the intersection of two lists in Ocaml:
let rec intersect lst =
function
[] -> []
| head :: tail ->
if List.mem head lst then
head :: intersect lst tail
else
intersect lst tail
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"They should make peace with those who make peace, and wage war
against those who wage war, and wage jihad against those who stand
in the way of spreading the message of Islam and causing it to
prevail of earth."
http://islamqa.com/index.php?ln=eng&ds=qa&lv=browse&QR=26721&am…
7:15 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
Erik de Castro Lopo wrote:
Now, << was left-associative, wasn't it? Or was it? ;-)
for (int
i=0;i<n;i++)
cout << i << endl;
Shouldn't you put parentheses around on or the other of those
left shift operators? :-) If you want pristine beauty, you should have a look
the function
to find the intersection of two lists in Ocaml:
let rec intersect lst =
[...]
To make this thread go totally off-topic, here's the same in Q:
intersect Xs [Y|Ys] = [Y|intersect Xs Ys] if any (=Y) Xs;
= intersect Xs Ys otherwise;
Now which one looks prettier? Sorry, couldn't resist. ;-)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
8:20 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
/me wrote:
To make this thread go totally off-topic, here's
the same in Q:
Sorry, I forgot one equation:
intersect Xs [] = [];
intersect Xs [Y|Ys] = [Y|intersect Xs Ys] if any (=Y) Xs;
= intersect Xs Ys otherwise;
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
9:41 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
Albert Graef wrote:
/me wrote:
Ah yeah, like Haskell and Erlang would do it.
I do prefer the Ocaml way :-)
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Perl as a language has less a design than a thousand special features
flying in close formation."
-- From the c2 wiki
To make this thread go totally off-topic,
here's the same in Q:
Sorry, I forgot one equation:
intersect Xs [] = [];
intersect Xs [Y|Ys] = [Y|intersect Xs Ys] if any (=Y) Xs;
= intersect Xs Ys otherwise;
9:51 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
for (int
i=0;i<n;i++)
cout << i << endl;
Shouldn't you put parentheses around on or the other of those
left shift operators? :-) let rec intersect lst =
function
[] -> []
| head :: tail ->
if List.mem head lst then
head :: intersect lst tail
else
intersect lst tail
Oooooh. I like the curves on that one.
Carlo
6:33 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
> Heh, I'm only a novice programmer, and
I'm already lazy :)
since this thread is so GTK+-centric i'll chime in and say ive found nothing i like
for easily creating customized/flexible GUIs more than Tcl/Tk and Ruby-on-Rails. both
tools allow me to do exactly what i want with minimal fuss - i still dont know anything
about C++ memory management and am grateful for ways to easily bring my ideas to life
without an advanced CS degree.
once going beyond sortable lists and selectorboxes, youre going to end up with some kind
of canvas, at which point TCL is very mature, and Gecko/XulRunner with its new
<Canvas> object is turning into nice option. or even python/ruby bindings to
Cairo...
cousins like ksycoca, kdeinit, klauncher etc. But this
isn't true with
gnome.
this is unfortunately true. if you are running openbox, or evilWM or what not, you might
as well be running KDE if you are ever going to us a KDE app. for example amarok will take
15 seconds to startup on the latest machine as all sorts of crap daemons loaded:
root 14912 0.0 0.5 71936 11292 ? Ss 09:40 0:00 kdeinit Running...
root 14915 0.0 0.1 69684 3156 ? S 09:40 0:00 dcopserver [kdeinit]
--nosid
root 14917 0.0 0.4 72404 8956 ? S 09:40 0:00 klauncher [kdeinit]
root 14919 0.1 1.0 97624 21360 ? S 09:40 0:59 kded [kdeinit]
root 14935 0.0 0.6 75868 12708 ? S 09:41 0:00 kaccess [kdeinit]
root 14938 0.0 0.6 74832 13016 ? S 09:41 0:00 ksmserver [kdeinit]
gnome apps do nothing of the sort
8:16 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
cdr wrote:
since this thread is so GTK+-centric i'll chime in
and say ive found nothing i like for easily creating customized/flexible GUIs more than
Tcl/Tk [...]
Not to forget there's also Gnocl which lets you program Gnome and GTK+
applications in Tcl: http://www.dr-baum.net/gnocl/
I've actually written a GUI builder for that which makes it possible to
click together simple Gnocl GUIs in a matter of minutes. (Currently the
builder only generates Q code, see below, but tacking on a Tcl backend
to it shouldn't be a big deal.)
I'm not sure how well Tcl integrates with MIDI, OSC and digital audio,
though. So, if you want/need to write the rest of the program in C then
Tcl might not be that helpful, unless you're willing to fiddle around
with SWIG (http://www.swig.org) or Tcl's C interface.
Shameless plug: Those interested in scripting languages might also
consider Q (http://q-lang.sf.net) which already has interfaces to
PortAudio, libsndfile, libsamplerate, Faust, MidiShare, SuperCollider,
OpenGL/OpenAL, Tcl/Tk/Gnocl and whatnot. This has the added benefit that
it's a functional language which makes it easy to deal with complex data
structures and symbolic processing. I'm currently doing the final
touches for the Q 7.0 release which also has full unicode support and
comes with the GUI builder I mentioned above. Scheduled to be released
Real Soon Now -- surely in time for LAC06. ;-)
once going beyond sortable lists and selectorboxes,
youre going to end up with some kind of canvas
Yes, having a good canvas widget certainly helps, and Tk has a nice one.
The one in Gnocl provides a similar interface while it is based on GNOME
Canvas. (Looks like GNOME Canvas isn't liked very much by some, but I
found it to be quite usable, at least in its Gnocl incarnation.)
Albert
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
11:35 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sun, 2006-26-02 at 01:17 +0100, Albert Graef wrote:
Yes, having a good canvas widget certainly helps, and
Tk has a nice one.
The one in Gnocl provides a similar interface while it is based on GNOME
Canvas. (Looks like GNOME Canvas isn't liked very much by some, but I
found it to be quite usable, at least in its Gnocl incarnation.)
Interesting fact: there is nothing good about GnomeCanvas.
Nothing.
:)
-DR-
26 Feb
26 Feb
12:45 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sat, 2006-02-25 at 22:35 -0500, Dave Robillard wrote:
Interesting fact: there is nothing good about
GnomeCanvas.
Nothing.
For any free form rendering I use Cairo or OpenGL nowadays. Better
performance and you get antialiased lines etc practically for free. And
what's most important, you don't have to care about pixel coordinates or
resolutions anymore (esp. in OpenGL).
- Jussi
3:37 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
Jussi Laako wrote:
For any free form rendering I use Cairo or OpenGL
nowadays. Better
performance and you get antialiased lines etc practically for free. And
what's most important, you don't have to care about pixel coordinates or
resolutions anymore (esp. in OpenGL).
Canvases give you much more than just rendering. They also manage the
graphical objects that you created and, if anything changes, rerendering
the changed parts happens automatically. Moreover, they let you inspect
the object model of the rendered graphic. Does Cairo do that for you?
OpenGL can do something like this with its display lists, but that's a
very low-level abstraction compared to what canvas widgets offer.
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
7:16 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sun, 2006-02-26 at 20:38 +0100, Albert Graef wrote:
Canvases give you much more than just rendering. They
also manage the
graphical objects that you created and, if anything changes, rerendering
the changed parts happens automatically.
That's usually bad and undesirable for any real time graphics rendering,
like audio UIs often are. For example with proper interfaces I can now
get full screen scrolling spectrogram at 50-100 fps without huge CPU
load.
Moreover, they let you inspect
the object model of the rendered graphic. Does Cairo do that for you?
Well, Gtk+ uses Cairo nowadays anyway... Coordinate transformations,
etc. make it reasonable to also get proper printer output.
OpenGL can do something like this with its display
lists, but that's a
very low-level abstraction compared to what canvas widgets offer.
Probably you could create proper canvas implementation on top of
Cairo/OpenGL, but most of the current implementations I've seen are dead
slow. I'm not sure if GnomeCanvas or some other implementation has been
converted to Cairo yet...
- Jussi
8:10 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Mon, Feb 27, 2006 at 01:16:17AM +0200, Jussi Laako wrote:
Correct.
Having done a lot of this stuff in earlier lifes, my conclusion is that
the right way to organise redrawing, scrolling, zooming etc. depends a
lot on the sort of data you want to display and how it is modified either
'from within' or as a result of user interaction.
I just can't imagine there could exist a single model that would handle
even a small selection of the situations I've encountered efficiently.
Every abstraction is based on some assumptions and I've seen them break
down time and time again.
When using X, you have a fundamental choice between drawing directly
to a window or to a pixmap. In the first case you must be prepared to
refresh anything at any time, and be organised to do this effeciently.
In the second case X will take care of refreshing newly exposed parts,
but you are using a limited resource (if the pixmap has to remain in
graphics memory for speed). I guess most canvases take the lazy (2nd)
route.
--
FA
On Sun, 2006-02-26 at 20:38 +0100, Albert Graef wrote:
Canvases give
you much more than just rendering. They also manage the
graphical objects that you created and, if anything changes, rerendering
the changed parts happens automatically.
That's usually bad and undesirable for any real time graphics rendering,
like audio UIs often are. For example with proper interfaces I can now
get full screen scrolling spectrogram at 50-100 fps without huge CPU
load.
27 Feb
27 Feb
11:50 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
Jussi Laako wrote:
I agree on that, I surely wouldn't want to draw waves or 3D
visualizations using a canvas widget either. ;-) But computer music
applications also need complex object views (scores, tracks,
arrangements, etc.) which can be manipulated by the user (selections,
drag and drop, etc.). Canvases are indispensable for that (well, you
certainly don't have to use an existing canvas implementation, but then
you probably end up doing your own).
--
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email: Dr.Graef(a)t-online.de, ag(a)muwiinfa.geschichte.uni-mainz.de
WWW: http://www.musikinformatik.uni-mainz.de/ag
Canvases give
you much more than just rendering. They also manage the
graphical objects that you created and, if anything changes, rerendering
the changed parts happens automatically.
That's usually bad and undesirable for any real time graphics rendering,
like audio UIs often are. For example with proper interfaces I can now
get full screen scrolling spectrogram at 50-100 fps without huge CPU
load.
26 Feb
26 Feb
9:30 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sun, 2006-26-02 at 18:45 +0200, Jussi Laako wrote:
On Sat, 2006-02-25 at 22:35 -0500, Dave Robillard
wrote:
For drawing, sure. The event handling (ie dragging objects around) is
the hard part...
-DR-
Interesting fact: there is nothing good about
GnomeCanvas.
Nothing.
For any free form rendering I use Cairo or OpenGL nowadays. Better
performance and you get antialiased lines etc practically for free. And
what's most important, you don't have to care about pixel coordinates or
resolutions anymore (esp. in OpenGL). 
3:14 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sat, 2006-02-25 at 16:56 +0200, Sampo Savolainen wrote:
On Sat, 2006-02-25 at 13:15 +0100, Carlo Capocasa
wrote:
I just want to point out, for those who do not already know, KDE is
not the same as Qt. KDE is built using Qt. I write most everything at
work using C++/Qt. I do not use any KDE libraries. I still get the
lovely printing, ftp, socket, mysql, etc widgets without having to run
any of the KDE stuff.
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
Heh, I'm only a novice programmer, and
I'm already lazy :)
Ah, the sign of a good programmer. :)
KDE and Gnome both appear greedy to me. They both
want me to use their
system and hence, tell me how to use my computer. Very little care is
taken to make sure individual parts can be used without installing the
whole whack. It's like I want to marry the girl I love but I can't
without also marrying her cousin, her sister and her aunt. This is the
Win/Mac philosophy, not the UNIX philosophy, and especially not the free
software philosophy.
It's true that with KDE you are marrying into KDE's family with bastard
cousins like ksycoca, kdeinit, klauncher etc. But this isn't true with
gnome.
5:58 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sunday 26 February 2006 08.11, Jan Depner wrote:
On Sat, 2006-02-25 at 16:56 +0200, Sampo Savolainen
wrote:
Just wanted to chime in with a, I concur.
If you want to build on a gui toolkit and get the least dependencies I think
neither Gnome nor KDE are the right choices. The real choices here are QT or
GTK. The choice is simple for me, QT, but that's just me...
As for other toolkits, there are soon as many as there are stars in the sky,
though most of them don't get installed on a standard system. I wonder how
widespread fltk is? I checked it out a very long time ago there was a lot of
things to like about it, small, gui-builder etc...
/Robert
--
http://spamatica.se/musicsite/
On Sat, 2006-02-25 at 13:15 +0100, Carlo Capocasa
wrote:
I just want to point out, for those who do not already know, KDE is
not the same as Qt. KDE is built using Qt. I write most everything at
work using C++/Qt. I do not use any KDE libraries. I still get the
lovely printing, ftp, socket, mysql, etc widgets without having to run
any of the KDE stuff. Heh, I'm only a novice programmer, and
I'm already lazy :)
Ah, the sign of a good programmer. :)
KDE and Gnome both appear greedy to me. They both
want me to use their
system and hence, tell me how to use my computer. Very little care is
taken to make sure individual parts can be used without installing the
whole whack. It's like I want to marry the girl I love but I can't
without also marrying her cousin, her sister and her aunt. This is the
Win/Mac philosophy, not the UNIX philosophy, and especially not the
free software philosophy.
It's true that with KDE you are marrying into KDE's family with bastard
cousins like ksycoca, kdeinit, klauncher etc. But this isn't true with
gnome. 
7:06 a.m.
New subject: [linux-audio-dev] Re: Which widgets
Robert Jonsson wrote:
neither Gnome nor KDE are the right choices. The real
choices here are QT or
GTK. The choice is simple for me, QT, but that's just me...
There's also wxWidgets
http://www.wxwidgets.org/whychoos.htm
Emanuel
7:30 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
2006/2/26, Robert Jonsson <rj(a)spamatica.se>se>:
As for other toolkits, there are soon as many as there
are stars in the sky,
though most of them don't get installed on a standard system. I wonder how
widespread fltk is? I checked it out a very long time ago there was a lot of
things to like about it, small, gui-builder etc...
I'm using fltk, and I quite like it, it's small and fast, and most
distris have it in their repositories, It compilies quickly, so it's
not a big issue if it's missing on the users system. There are also
quite a few nice fltk-based apps, so I guess most audio users might
have it on their boxes as well.
I switched from wxWidgets to fltk, and I do net regret it because it
offers almost the same cross-platform capablities (X11, OSX, win32),
while it's headers are much smaller, which results in faster compile
times, and this is convinient during development. There are some
things that I'm missing, that wx has, but I've always found ways to
work around these shortcomings.
-Richard
25 Feb
25 Feb
11:29 p.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sat, 2006-25-02 at 13:15 +0100, Carlo Capocasa wrote:
This is much less true of GNOME than KDE, FWIW.
-DR-
I'm a
programmer = I'm lazy = I don't want to write printing dialogs, or
VFS support, especially since it's already provided by gnome.
Heh, I'm only a novice programmer, and I'm already lazy :)
I think widgets are a GOOD thing. I also think modularity is a good thing.
KDE and Gnome both appear greedy to me. They both want me to use their
system and hence, tell me how to use my computer. Very little care is
taken to make sure individual parts can be used without installing the
whole whack. It's like I want to marry the girl I love but I can't
without also marrying her cousin, her sister and her aunt. This is the
Win/Mac philosophy, not the UNIX philosophy, and especially not the free
software philosophy. 
10:56 a.m.
New subject: [linux-audio-dev] Re: Which widgets?
On Sat, 2006-02-25 at 12:39 +0100, Carlo Capocasa wrote:
Personally, I'd love to see more GTK2 apps
around.
I think it's the oldest *full featured* toolkit around and I think even
the bloat is bearable (just keep your hands off anything that says 'Gnome')
Motif is pretty old and full featured, but it's PITA to use, IMO...
- Jussi
4:52 p.m.
James,
I normally prefer Qt but when I started working with JAMin Steve got
me started using GTK (no one wanted to switch to C++ from C). We used
Glade to build the graphics structure and it is really simple and easy
to use. If you want to stay in C I would suggest trying that.
On Sat, 2006-02-25 at 01:14 +0000, james(a)dis-dot-dat.net wrote:
Hello all.
I've always steered clear of writing GUIs, so my experience is pretty
limited. But now I find myself needing a toolkit/widget set.
What's recommended? I'd prefer not to have to move my app from C to
C++ just to implement the interface, so that's quite a few out of the
window.
I don't really want huge dependencies for a knob, text box and a
button, either.
And something that's installed as default in most distros would be
good, too.
So, what I want is everything. And it should be simple, too.
Any suggestions?
James
--
Jan 'Evil Twin' Depner
The Fuzzy Dice
http://myweb.cableone.net/eviltwin69/fuzzy.html
"As we enjoy great advantages from the invention of others, we should be
glad of an opportunity to serve others by any invention of ours, and
this we should do freely and generously."
Benjamin Franklin, on declining patents offered by the governor of
Pennsylvania for his "Pennsylvania Fireplace", c. 1744
11:25 p.m.
On Sat, 2006-25-02 at 01:14 +0000, james(a)dis-dot-dat.net wrote:
Hello all.
I've always steered clear of writing GUIs, so my experience is pretty
limited. But now I find myself needing a toolkit/widget set.
What's recommended? I'd prefer not to have to move my app from C to
C++ just to implement the interface, so that's quite a few out of the
window.
I don't really want huge dependencies for a knob, text box and a
button, either.
And something that's installed as default in most distros would be
good, too.
GTK
-DR-
26 Feb
26 Feb
5:34 a.m.
New subject: [linux-audio-dev] Mitch The Midget (was: Re: Which widgets?)
Everyone say this one real fast:
Which widget's Mitch the midget's,
Mitch the midget's widget's which?
6641
days inactive
6644
days old
linux-audio-dev@lists.linuxaudio.org
33 comments
16 participants
participants (16)
-
Albert Graef -
Carlo Capocasa -
cdr -
Dave Robillard -
Emanuel Rumpf -
Erik de Castro Lopo -
fons adriaensen -
james＠dis-dot-dat.net -
Jan Depner -
Jussi Laako -
Lars Luthman -
Lee Revell -
Loki Davison -
Richard Spindler -
Robert Jonsson -
Sampo Savolainen