[<<] [<] Page 1 of 2 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
GUILib for C
From: ####@####.#### Date: 18 Dec 2000 15:45:31 -0000 Message-Id: <OF66087349.F914DB09-ONC12569B9.0056BA84@mn.man.de> Hi! There is a lib for C, which looks good and is relatively small: http://www.cs.su.oz.au/~loki/graphapp/ The bad thing: It does need an additional widget set, like Xaw to run. --- Martin | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Alex Holden ####@####.#### Date: 18 Dec 2000 16:17:03 -0000 Message-Id: <Pine.LNX.4.04.10012181608060.870-100000@hyperspace.linuxhacker.org> On Mon, 18 Dec 2000 ####@####.#### wrote: > There is a lib for C, which looks good and is relatively small: > http://www.cs.su.oz.au/~loki/graphapp/ > The bad thing: It does need an additional widget set, like Xaw to run. Hmm, I think that's really more of a toolkit abstraction layer than a toolkit itself. Here's a cool idea: How about hacking something together from Enlightenment's built in toolkit? It's actually pretty small and clean, and most of the X interface is already abstracted out into the functions in x.c... The only slight disadvantage is the BSD advertising clause. -- ------- Alex Holden ------- http://www.linuxhacker.org/ http://www.robogeeks.org/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Jordan Crouse ####@####.#### Date: 18 Dec 2000 16:28:45 -0000 Message-Id: <3A3E3C27.22EBABCB@censoft.com> Instead of hacking an existing toolkit, would it really be tough to start from scratch and design a lightweight and quality toolkit exclusively for Nano-X that can be dropped in and used with little pain and/or suffering? I know there are alot of folks on this list that are begging for things to do, and that would be a great way to help the project, and learn about Nano-X at the same time. That might be just as good as "hacking" in something else, plus we could put a MPL on it to begin with and not have to deal with any other licencing issues. Jordan Alex Holden wrote: > > On Mon, 18 Dec 2000 ####@####.#### wrote: > > There is a lib for C, which looks good and is relatively small: > > http://www.cs.su.oz.au/~loki/graphapp/ > > The bad thing: It does need an additional widget set, like Xaw to run. > > Hmm, I think that's really more of a toolkit abstraction layer than a > toolkit itself. > > Here's a cool idea: How about hacking something together from > Enlightenment's built in toolkit? It's actually pretty small and clean, > and most of the X interface is already abstracted out into the functions > in x.c... > > The only slight disadvantage is the BSD advertising clause. > > -- > ------- Alex Holden ------- > http://www.linuxhacker.org/ > http://www.robogeeks.org/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ####@####.#### > For additional commands, e-mail: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Alex Holden ####@####.#### Date: 18 Dec 2000 16:49:33 -0000 Message-Id: <Pine.LNX.4.04.10012181636320.870-100000@hyperspace.linuxhacker.org> On Mon, 18 Dec 2000, Jordan Crouse wrote: > Instead of hacking an existing toolkit, would it really be tough to > start from scratch and design a lightweight and quality toolkit > exclusively for Nano-X that can be dropped in and used with little pain > and/or suffering? Ok, the reason I've been hoping we could avoid this is that it takes a lot of work to write a decent toolkit. If we do decide to go down this route, the question is whether we should start from nanowidgets or abandon it and start again from scratch. -- ------- Alex Holden ------- http://www.linuxhacker.org/ http://www.robogeeks.org/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Jordan Crouse ####@####.#### Date: 18 Dec 2000 17:04:44 -0000 Message-Id: <3A3E448F.3D6DEE62@censoft.com> I know, I know, it goes against every Open Source inclination that I have ever had too, but I mention this purely for the fact that Nano-X has yet to have a toolkit that is designed specifically for it, and not just something that we brought across from X. I mean, we might as well have written FLNX from scratch for all the work we have put into it trying to get it to work with Nano-X. It does take a ton of work to design a decent toolkit, but will the ends justify the means? I would see most of the work being put into the design stage. Once we are beyond that, then we could add widgets in a modular fashion. For example, given a very specific framework, I could add a button widget that I need, and then later on, if you needed a password entry field for your authentication, then you could add it at your leisure. The important thing would be to design a very good framework that would make this easy for all involved. Really, its not tough to draw a button -- the tough part is designing it so that it fits into a grander scheme. I don't know the state of the nanowidgets kit, but I would ask - Why was it dropped? Were they hard to use, or did nobody really care that much? Unless you are working on new hardware or staring at the Nano-X engine 8 hours a day, it is hard to find your place as a contributor to this project. I would think that a new widget set would give development opportunities to a whole new core of programmers that are interested in helping, but having trouble finding a niche. But then again, I have been wrong many times in the past. What do others think of this? Jordan Alex Holden wrote: > > On Mon, 18 Dec 2000, Jordan Crouse wrote: > > Instead of hacking an existing toolkit, would it really be tough to > > start from scratch and design a lightweight and quality toolkit > > exclusively for Nano-X that can be dropped in and used with little pain > > and/or suffering? > > Ok, the reason I've been hoping we could avoid this is that it takes a > lot of work to write a decent toolkit. If we do decide to go down this > route, the question is whether we should start from nanowidgets or abandon > it and start again from scratch. > > -- > ------- Alex Holden ------- > http://www.linuxhacker.org/ > http://www.robogeeks.org/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Alex Holden ####@####.#### Date: 18 Dec 2000 17:41:59 -0000 Message-Id: <Pine.LNX.4.04.10012181705550.870-100000@hyperspace.linuxhacker.org> On Mon, 18 Dec 2000, Jordan Crouse wrote: > beyond that, then we could add widgets in a modular fashion. For > example, given a very specific framework, I could add a button widget Yep, that's probably the nicest thing about nanowidgets- the extremely lightweight C class framework. One thing it doesn't have which I would like to see is dynamic positioning and resizing of widgets like Gtk+ ie. the application specifies the relative locations of the widgets, and the toolkit decides exactly where to place them and how big they are. The application doesn't have to worry about details like exactly how much space a text field needs (which varies with the font used, so hard coding it is a bad idea), or where to place it to get it exactly in the middle of a window. If the user then resizes the window, it goes through resizing and repositioning all the widgets automatically. When a widget gets a resize event, if it's a container it passes the event on (possibly modified) to it's children, and if it's not a container it redraws it's contents at the new size. So in the case of standard widgets like text fields, the application doesn't need to do anything at all when the when the window is resized. > this easy for all involved. Really, its not tough to draw a button -- From my perspective, the hardest thing is making it look nice. What we could do with is someone with some artistic ability :) > I don't know the state of the nanowidgets kit, but I would ask - Why was > it dropped? Were they hard to use, or did nobody really care that much? I think it's just that nobody has been working on it except for Screenmedia. I'm not sure what the latest status is with regard to them sending us their latest code. They said they were going to look into it, but felt it unlikely that their managers would let them release it until they actually release their product based on it (they regard the look and feel of it a trade secret or something). Legally they're perfectly within their rights to do this until they release a product which uses it. > Unless you are working on new hardware or staring at the Nano-X engine 8 > hours a day, it is hard to find your place as a contributor to this > project. I would think that a new widget set would give development > opportunities to a whole new core of programmers that are interested in > helping, but having trouble finding a niche. But then again, I have > been wrong many times in the past. What do others think of this? Maybe. Perhaps if we get a basic working core and some demo apps in place, people will come along and write the more complex widgets (file selector, scrolling text window, canvas, etc.) for us... -- ------- Alex Holden ------- http://www.linuxhacker.org/ http://www.robogeeks.org/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Kaben Nanlohy ####@####.#### Date: 18 Dec 2000 21:25:57 -0000 Message-Id: <Pine.NEB.4.21.0012181200340.14684-100000@kaben.frye.com> On Mon, 18 Dec 2000, Alex Holden wrote: > On Mon, 18 Dec 2000, Jordan Crouse wrote: > > beyond that, then we could add widgets in a modular fashion. For > > example, given a very specific framework, I could add a button widget > > Yep, that's probably the nicest thing about nanowidgets- the extremely > lightweight C class framework. After the first compile and run of demos w/nanowidgets, I wasn't able to muster much enthusiasm. At the time the toolset had more problems than it does now (it dumped core if I blinked). With all of its macro magic for object-orientedness, after several hours of plotting out program flow I sort of gave up trying to troubleshoot nanowidgets. I expect those with C++ vocabs and mindsets have had an easier time. But my $0.02 worth: if a widget set is going to be created from scratch, can we stick to C unions and structs and functions in implementing our classes? Or maybe this a personal preference sort of thing. I have object-oriented tendencies because I used to use java; and i know that object-oriented programming in straight C doesn't require use of macros. > > I don't know the state of the nanowidgets kit, but I would ask - Why was > > it dropped? Were they hard to use, or did nobody really care that much? > > I think it's just that nobody has been working on it except for > Screenmedia. I was planning to use nanowidgets in my projects. Wanted to, anyway, at the outset. I'd use the nanowidgets kit if it became reliable or at the very least if could figure out how to troubleshoot it. I haven't tried lately, but I've noticed that the demos don't crash as easily as they used to. > > Unless you are working on new hardware or staring at the Nano-X engine 8 > > hours a day, it is hard to find your place as a contributor to this > > project. I would think that a new widget set would give development > > opportunities to a whole new core of programmers that are interested in > > helping, but having trouble finding a niche. But then again, I have > > been wrong many times in the past. What do others think of this? > > Maybe. Perhaps if we get a basic working core and some demo apps in place, > people will come along and write the more complex widgets (file selector, > scrolling text window, canvas, etc.) for us... I'm interested in this. I spend alot of time banging on Nano-X and RTEMS in an embedded application, and since I'm under the gun I haven't been putting too much energy into general apis. But I'd be happy to start doing that sort of thing, and I'll be able to contribute quite a bit after the start of the new year. -- Kaben Nanlohy | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Alex Holden ####@####.#### Date: 18 Dec 2000 22:06:22 -0000 Message-Id: <Pine.LNX.4.04.10012182128580.870-100000@hyperspace.linuxhacker.org> On Mon, 18 Dec 2000, Kaben Nanlohy wrote: > After the first compile and run of demos w/nanowidgets, I wasn't able to > muster much enthusiasm. At the time the toolset had more problems than it > does now (it dumped core if I blinked). With all of its macro magic for > object-orientedness, after several hours of plotting out program flow I > sort of gave up trying to troubleshoot nanowidgets. Ah, you spotted the obvious flaw- the reason the widget class stuff is so clean and simple to use is because of the complex macros that do most of the work for you behind the scenes, which can be a pain to debug if the bug is in the macros... > But my $0.02 worth: if a widget set is going to be created from scratch, > can we stick to C unions and structs and functions in implementing our > classes? It is based on structures and callbacks just like you'd expect; the macros just hide the complexity from the programmer. My main complaint about them is that it's not completely obvious how to use them and there isn't any documentation, but it's actually quite elegant once you see how it works. We could replace the macro generated object structures with explicitly defined structures and replace the macros which do things like creating and destroying objects, but it would require the programmer to write more code. Swings and roundabouts. Remember the original C++ compiler was even worse- instead of a few relatively simple C macros, it used a complex preprocessor. Actually I think if I was to start again from scratch, I probably would go the route of making things more explicit even though it generates more work for the programmer, but that's just a personal preference. -- ------- Alex Holden ------- http://www.linuxhacker.org/ http://www.robogeeks.org/ | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Nick Papadonis ####@####.#### Date: 19 Dec 2000 08:44:48 -0000 Message-Id: <m3zohsnc0r.fsf@wash-382.res.umass.edu> The problem with a new toolkit is that using it requires knowledge of a new API. That is where embedded QT shines. >>>>> "Jordan" == Jordan Crouse ####@####.#### writes: > Unless you are working on new hardware or staring at the Nano-X > engine 8 hours a day, it is hard to find your place as a > contributor to this project. I would think that a new widget > set would give development opportunities to a whole new core of > programmers that are interested in helping, but having trouble > finding a niche. But then again, I have been wrong many times > in the past. What do others think of this? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: GUILib for C
From: Andrew Kenneth Milton ####@####.#### Date: 19 Dec 2000 10:12:51 -0000 Message-Id: <20001219201803.Q2979@zeus.theinternet.com.au> +-------[ Nick Papadonis ]---------------------- | The problem with a new toolkit is that using it requires knowledge of | a new API. That is where embedded QT shines. Assuming you already know embedded QT, and there's no interface layer. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew Milton The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 2 [>] [>>] |