On Wed, Feb 17, 2010 at 8:24 AM, LightningIsMyName <lightningismyname@xxxxxxxxx> wrote: > Hello > > On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death <alexiadeath@xxxxxxxxx> wrote: > 2. The painting of the matrix as showed in the specifications seems > very hard, and I doubt it worths it. We can easily implement different > colors for each row, and users will have to settle for a little border > between the columns. http://www.pygtk.org/docs/pygtk/class-gtktreeview.html Looks like it is possible to disable cell borders (and I think it may be necessary when the cells are small like this-- we want to avoid the borders visually overwhelming the cell content. > If we agree to give up the proposed matrix > painting and choose what I suggested, it can be done with GtkTreeView > without any special changes, but it will leave the simpler GtkTable > our of the question (which is fine with me). > 3. Adding the images with the link's color should be a bit tricky, but > I assume that it can be done dynamically (by drawing those images > after acquiring the link's color, instead of embedding ready bitmaps). > 4. Popup window: Part 1 - the curves widget. This can definetly be > stolen from the curves tool, no need to work twice. The only needed > modification is that we can show some other curves at the background, > and that we add min and max arrows. > 5. Popup window: Part 2 - switching the tabs. This doesn't seem to > bad, especially since we already have similar functionality in the > curves tool. > > only two things seem problomatic: > A treeview widget can't have a bitmap in it's header, And adding the > bitmaps as the first row is ugly and probably not the right way to do > this. The guys on the GTK mailing list will probably be able to help > us out here. > And another questions is, why do we have the same header images at the > bottom? Adding a footer to a GtkTreeView isn't possible. Do we really > need that? Here i'm defintly sure it's not worth the coding amount > that it will require, and I personally find it confusing. I believe that this kind of measure is usually taken when the number of input variables is anticipated to increase (so perhaps you won't be able to see the top and bottom at the same time) > > I haven't seen anything that scary in here, but I doubt that I'll have > time to touch it in this month. If I implement something like this on > a dummy GtkWindow (instead of hacking GIMP's source code, which I > don't excel at) as a stand-alone Gtk application, will it help? > If so, I'll try to give it a shot. > If you want to see how to use the TreeView and the CellRenderer, the > gtk-demo program (which comes with GTK) has a nice example under "Tree > View/List Store". The code is very simple and in one of the columns > you'll see the Toggle renderer. > >> for example, one dock needs to hold 2.5 distinct views > I haven't understood that sentence. Can you please explain (or, have I > referred to it already)? I think I understood it: one dockable must hold a) the matrix, b) the input mapping, and c) the output mapping I thought this was a fairly simple problem in GTK terms. 1. Put the matrix inside its own VBox. Pack it at the start of the window. (This may require nesting inside another VBox.) 2. Put the input and output mapping in another VBox (one they share.) in the following manner: 1. Presets (shared between input and output) 2. Inputs selector 3. Outputs selector 4. Curve display (shared?) 5. 'Inputs' label 6. 'Outputs' label 7. Inputs treeview 8. Outputs treeview 9. 'Show current <INPUT NAME> input' 3. When switching modes, we: 1. If switching to matrix mode, hide the input/output vbox. Show the matrix vbox. Done. 2. If switching away from matrix mode, hide the matrix vbox. 3. If switching to inputs or outputs mode, we need to iterate over the widgets in the VBox; Hide any widgets not specific to the mode in question. I think there is a widget grouping mechanism in GTK that allows for this kind of distinction. That is in fact somewhat ugly. There is probably another solution involving packing the input/output widgets on the fly. That would be neater code-wise, and somewhat slower. I don't know whether the above would argue with the dockable's idea of how tall it ought to be. That might be what Alexia was talking about. > Just one offtopic comment: Some of the icons seem very unintuitive - > even as an "old" GIMP user I'm still confused by the fifth one from > the left. What does it stand for? It looks like it's probably meant to be 'random'. I got that from the list, not the graphic, though. _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
