Re: Sheet and Drawer widgets
W liście z czw, 15-07-2004, godz. 22:58, Owen Taylor pisze: > On Wed, 2004-07-14 at 22:47, Ken Harris wrote: > > I once saw an interview with Owen Taylor where he said he'd like to see > > somebody implement Mac-style drawers, for possible inclusion in some > > future version of Gtk+. Being crazy (or dumb) enough to think this > > would be easy, I decided to give it a try. You can see what I've done > > so far: > > > > http://bitpoetry.com/programs/gtksheetsanddrawers/ > > > > It's not something you can really use yet, but it's kind of fun to play > > with. The next step is to make them into real GtkWidgets, and polish > > them up so they're usable in real applications. If you want to help, > > please do! I'm new to Gtk+ and still trying to figure this stuff out. > > Cool, cc'ing gtk-devel-list on the response so that the appropriate > set of people see this. (Usually we are trying to chase things *off* > gtk-devel-list...) Cool thing, especially sheets are totally sweet idea, but I have some concerns regarding drawers. Back in pre-aqua, QTPlayer 4.0[1] days, when Apple was only introducing drawers (using them for playlists), they were quite cumbersome from UI POV. They had serious problems with screen real estate, which influenced how much of drawer is visible, and if there wasn't enough space, they wouldn't show up at all. Now that drawers seem standard and heavily used part of OSX, are these issues somehow solved? [1] It's actually hard to believe it was made by apple, it sucked so hard in UI area. Cheers, Maciej -- "Tautologizm to coś tautologicznego" Maciej Katafiasz <[EMAIL PROTECTED]> http://mathrick.blog.pl ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
Re: simple text editing
Dnia 21-12-2004, wto o godzinie 08:34 -0800, [EMAIL PROTECTED] napisał: > Hello, > > I'm very new to GTK and Linux programming in general-- I come from a Win32 > background. I am very fond of the free software movement and for that > reason, among others, have chosen gnome to use as my environment and have > chosen to learn GTK+/Gnome programming. > > I do a bit of programming for an embedded 8-bit programmer known as a PIC. > It has a very small instruction set and is compiled using a program known > as gpasm. I wanted to create a small text editor with syntax highlighting > for it's asm syntax and have the assemble callable from within the editor > and show the output in the output window-- basically a lightweight and > minimal IDE for a PIC. > > My question is, would this type of thing be doable via plugins for GEDIT > and if so, can someone point me in the right direction? I'd rather not > reinvent the wheel. GEDIT is perfect if I can find a way to add my syntax > highlighting and create a dialog for calling the assembler. > > If GEDIT is not the way to go, does anybody know of a good way to approach > this project. I realize I have a lot of learning to do. I have two books > on the subject of GTK and/or Gnome developement and have been tinkering > within the Anjuta IDE-- but am ultimately a "newbie". Any advise would be > much appreciated. You might be better off with emacs -- there's plenty of modes written for it, and basically there's almost nothing that can't be added. Guess what editor I use ;) Cheers, Maciej PS. Of course the price is that emacs is not as straightforward to use right away as GEdit, especially if you have Win32 background, but OTOH it's heavily optimised for being intensive-use editor. GEdit is much simpler, but IMHO is better as quick viewer rather than tool you use for heavy programming. It's all matter of taste, though, so YMMV -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Problem in using gtk_window_set_transient_for()
Dnia 23-12-2004, czw o godzinie 16:12 +0530, abhijeet singh panwar napisał: > Hi, > > I am using gtk_window_set_transient_for(GtkWindow *win2, GtkWindow *win1) > to keep one window win2 above another window win1 in my application. I > call this function just after creating win2 (win1 is already created). > When i run my application the win1 appears on screen but win2 doesnt > appear. And the application hangs. Please suggest what should i do? did you call gtk_window_show(win2) before? does this work? Cheers, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to create round shape push buttons
Dnia 24-12-2004, pią o godzinie 10:40 +0530, abhijeet singh panwar napisał: > Hi, > > I am new to GTK. Is there any way to create round shaped push buttons > with different colors. And on clicking on the button the color of the > button should change. You can first try (simpler approach) where you have two images, one being the image you want to show on button, and second being the same image with different colours you want to show in clicked state. Now, you set pixmap as child of button in question, fill it with image1, and catch "button-pressed" (or whatever's appropriate) signal, on which you replace pixmap's contents with image2. On "button-release" you revert pixmap back to image1. Advantages of this approach are simplicity and non-intrusiveness, disadvantage will be that button will catch clicks on entire rectangular area it has allocated, not only on visible pixels of your image. If you don't want that, then you need to subclass GtkButton and override appropriate methods and signal handlers so that it draws as image and does whatever you want when clicked. You get more control here, but also more work needs to be done. HTH, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Stuff I want to do with a combobox
Dnia 25-12-2004, sob o godzinie 08:00 -0500, Hudson Lee napisał: > Speaking of improving gtk combo boxes there is one thing about gtk combo > boxes I can't stand! If your combobox is near the top or bottem of the screen > it doesn't position itself so you can see all the items. For example say your > combobox is near the top of the screen and you have selected the item at the > very bottem of your list of choices. Now when you click on the combobox you > can't see the choices near the beginning of the list without using the arrow. > This is beacuse the combobox is drawn with the currently selected choice > apearing where you click. Is there anyway for an app programmer to change > this > behavior? What are some gtk developers thoughts on changing the way > comboboxes > are drawn so they work like every other pulldown menu in this regard? AFAIK this is entirely deliberate, to ensure that when you click on combobox to see list and then click again without moving mouse, selected item will not change. One implication is that in edge-cases combobox will be drawn with most items hidden behind scroll-arrows, but also ensures interface stability, which is of prime importance. That's probably good trade-off, interface that changes without user's action is Really Bad Thing(TM) Cheers, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gtk+ GIMP and GNOME
Dnia 11-02-2005, pią o godzinie 12:32 -0600, Eckhoff, Michael A napisał: > How much interaction is there nowadays between Gtk+ and the GIMP > project? I understand Gtk's origins, but am curious about the > current relationship. And likewise with GNOME. Today GIMP project is simply big user of GTK+ that provides significant testing of some more awkward use-cases due to its specific nature, and also several GIMP hackers are active GTK+ hackers, but that's about all. GNOME is today the largest GTK+ user, and also the most influential to its development, but still it is only a user of GTK+, which itself is fully independent project with its own goals. > The reason I ask, is because I was thinking about saving some > Drawables in GIMP's layered image format and using some of their > routines. Is the GIMP library a subset of Gtk+, or do I have to > link to it as well? libgimp is separate library, you need to link to it separately. > And can I export a drawable to a .ps or .pdf > file? No, at least not until Cairo is fully integrated, which will happen in 2.8 (but even then, you still need to have appropriate Cairo backends for pdf and ps, which aren't there yet). But if you use libgimp, it should be possible to at least export to PS, I think. > I need to plot some scientific data (e.g. vector fields, > contour plots, text labels, etc.) and it would be nice to be > able to add or remove certain features. I like the GNOME Canvas but > am concerned about its future. I have heard that this is no longer > maintained? If so, are the Gtk developers considering making it > into a GtkCanvas? (btw what's foo canvas?). Canvas is one recurring issue, inclusion of Cairo should help with it. FooCanvas is simple and easy to use canvas developed by and for Gnumeric, currently being split into separate library on its own (hope I didn't screw anything in this description) > Finally, what are the odds of getting any of this ported over > to MS Windows down the road? I know Gtk is cross-platform, but > am not sure about GIMP and GNOME. GIMP is fully cross-platform. GNOME isn't, it's strongly tied to Unix in more ways than GTK+ covers and that rather won't change in any forseeable future. HtH, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK Script?
Dnia 14-03-2005, pon o godzinie 00:18 +0100, Peter van Eerten napisał: > Being used to Desktop Korn Shell (DTKSH) with the Digital Unix Common > Desktop Environment, I wonder if something similar can be created for > GTK? Would it not be nice to have a scripting language which is also > capable of creating graphical user interfaces? > > Such a 'shell' could be distributed as part of GTK, and could have a > similar syntax as, say, BASH. So where ever GTK is installed, the user > always has the possibility of writing a quick script which produces a > GUI. If distributed with GTK it will not be dependent to any desktop, as > is the case with DTKSH. Check out Zenity, http://freshmeat.net/projects/zenity HTH, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK high speed interface
Dnia 29-04-2005, pią o godzinie 09:14 +1000, Tim McCoy napisał: > If I "single step" my emulator, then each of the register values are > displayed in the appropriate field. However, if I run the emulator (for > some 130,000 cycles, each cycle with a callback to place text in the > entry fields), then no text is written to the entry elements until the > entire program is finished. The interface itself appears to lock up, but > I (partially) understand the reasons for this. [snip] GUI won't get updated until you return to GTK+ main loop. To remedy that, you want to use gtk_events_pending (). See docs at http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#id2755523 they have snippet to put in your code. Cheers, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: compiler application error
Dnia 29-04-2005, pią o godzinie 00:26 -0700, nguyen tuan nghia napisał: > Why i can't compiler this program. [snip] > bash-2.05b# gcc -c libskindetect.c -o libskindetect > `pkg-config --cflags --libs > gtk+-2.0 glib-2.0` > gcc: --export-dynamic: linker input file unused > because linking not done [snip] You're using -c option to gcc which tells the compiler to not link resulting program, only to compile source into .o files. It has told you that, too :). Remove -c flag to make it compile and link. Cheers, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Variable Naming convetions...
Dnia 01-05-2005, nie o godzinie 20:43 -0700, [EMAIL PROTECTED]
napisał:
> Since I'm new to GTK+ programming, I would like to use conventional
> variable naming if at all possible. I've read that functions are in the
> format..
>
> some_function_name()
>
> and objects are...
>
> ThisIsSomeWidget
>
> and regular variables are...
>
> this_variable_is_like_a_function
>
> Is this correct?
If by ThisIsSomeWidget you mean type name, then yes, it's correct. If
this is object instance, however, then you'd rather follow normal
variable naming, like
GtkWidget* main_window;
Also, for enums and macros you use all caps, like
enum
{
GTK_SOME_ENUM_VALUE
} GTK_SOME_ENUM;
#define GTK_SOME_MACRO
unless the macro is intended to be used like normal function, in which
case you use function naming convention.
Cheers,
Maciej
--
Maciej Katafiasz <[EMAIL PROTECTED]>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Unforgiving GtkEntry
Dnia 04-05-2005, śro o godzinie 11:29 +0200, Egon Andersen napisał: > Hi, > > I've discovered a problem that I can't really determine if it is a bug > or intended. [snip] >From your description it looks like genuine bug. Just go ahead and file it, so it won't get lost, in case it's intended behaviour the bug will simply get closed. So don't be afraid of reporting, it's never the wrong thing to do :) Cheers, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Cairo and GTK+
Dnia 22-05-2005, nie o godzinie 12:55 -0400, Scott Robert Ladd napisał: > While I've been able to implement some of what I want using GnomeCanvas, > it appears that Cairo provides more of what I need for my project. > > Given that GTK+ 2.7 (the beta for 2.8) is about to be released, I'm > leaning toward waiting for it, rather than continuing to using Cairo 0.4 > as it stands now. > > Will Cairo-standalone be deprecated in favor of GTL+ 2.8's use of Cairo, > or will Cairo continue as a separate library? Cairo will remain separate library, work that's going on in 2.8 to integrate with Cairo means you'll be able to use it with GTK+ easily, as well as that GTK+ itself will use Cairo, but it doesn't mean Cairo will be swallowed by GTK+. If you're using it today, just continue doing so, and after 2.8 you'll find your current Cairo work easier, not redundant. Cheers, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Quick Question
Dnia 24-05-2005, wto o godzinie 09:37 -0400, Michal Porzuczek napisał: > I was wondering where do I post questions that I have concerning GTK? For example, to gtk-list@gnome.org :). If you have question that specifically covers application development with GTK+, you can use gtk-app-devel@, for all other questions (licensing, compiling, etc.), use gtk-list. Cheers, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: [slightly OT] non-blocking rpc-like thing?
Dnia 27-05-2005, pią o godzinie 08:29 -0700, Ben Johnson napisał: > I'm using an embedded perl interpreter in my app right now. This is > source of some inconviniences, so I'm thinking about moving the perl > piece into a seperate process. In order to make this worthwhile I'll > need an interface that can work with the gtk main loop (i.e. something > that uses file descriptors for communication) and a function set (an > API) that has support for a non-blocking interaction. > > Basically, in addition to basic rpc-like functionality, I want the API to: > - handle the EAGAIN return value properly > - provide a way for the calling app to initiate multiple reads or writes > for each interaction (for each procedure call), and inform the app > when the io is complete. > > preferably there are already both C and perl interfaces to this lib. I > haven't found anything that matches too closely so far. Anyone else > know of something? How difficult do you think it would be to make an > existing rpc lib non-blocking? D-BUS? http://www.freedesktop.org/Software/dbus Cheers, Maciej -- Maciej Katafiasz <[EMAIL PROTECTED]> ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How is GtkTreeIter->stamp initialized?
Dnia 04-07-2005, pon o godzinie 16:22 +0700, kyanh napisał:
> How is GtkTreeIter->stamp initialized?
>
> I mean: Is it possible that iter.stamp has a negative value?
GtkTreeIter is fully opaque, and readable only for its owner, that is,
{Tree,List}Store that created it. You never need to read nor interpret
the stamp.
Cheers,
Maciej
--
Being really good at C++ is like being really good at using rocks to
sharpen sticks. (Thant Tessman)
----
Maciej Katafiasz <[EMAIL PROTECTED]>
http://mathrick.org
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
