On Tuesday 04 of September 2012 12:08:11 Matthew Barnes wrote: > On Sun, 2012-09-02 at 00:16 +0200, Dan Vratil wrote: > > Unfortunately API of the Gtk widget totally _SUCKS_, so it's more of a > > hack. It's point is to make the color chooser to accept color by single > > clicking it instead of double clicking. > > Perhaps the new GtkMenuButton in GTK+ 3.6 might help here? Perhaps you > could subclass GtkMenuButton instead of GtkColorChooserWidget, but still > embed GtkColorChooserWidget in your subclass.
The problem is in the GtkColorChooserWidget itself. It's just a layout that wraps GtkColorSwatch, which is the actual color picker widget. The problem is that GtkColorSwatch is not a public widget (whyyyy?) and only emits "activate" on color when you double-click it. So I have to hack in, override the widget's press-event and manually emit "activate" on the swatch on single click. Since we are aiming for 3.8 with this I hope to make Gtk devs see how much stupid this is and propose/provide something better. Until then we will live with the hack :) > > > EActionComboBox - I dragged this from /widgets/misc, because I need it in > > the> > > Editor, but libeeditor can't link against libemiscwidgets (it links > > against libeeditor). > > Yeah, I'm toying with the idea of merging all these base libraries into > one. libeutil + libemiscwidgets + libetimezonedialog + libetext + > libetable + libemenus + ... there's just way too many already. > > Linking to all these shared libraries from layers higher up is a real > PITA and probably increases our startup time since each shared library > has to be loaded serially. Unless your filesystem is a real mess, I'm not sure that the startup time will increase significantly. But I agree that the amount of libraries is getting a bit out of hand. My humble proposal would be something like libeaddressbook, libecalendar, libemail and libecommon (everything used by more then one module). It would probably require mangling of the classes....and it's very-OT for the scope of this mail :) > > > The "Undo"/"Redo" actions might be slightly broken/inconsistent with > > Gtkhtml as well, because I don't have access to the action stack of > > WebKit, and WebKit records only some actions. I'm using these actions I > > know that WebKit records to do most of the formatting/DOM manipulation, > > but on some places it's just not possible to get the right result this > > way. > > That's a little more concerning. Maybe we can work with the WebKit guys > to expose more of the undo framework? We'll see if they will be willing to work on it. I'm afraid most of their resources is dedicated to WebKit2 API. > > > I'll write a blog post when the port is merged to master. I'd like to > > do the merge as soon as possible, because my time to continue working > > on it will be more and more limited during the semester, so the sooner > > you can test and report back the better. Feel free to start testing > > already (you can use the e- editor-test utility to test the editor > > itself). If you want to report bugs, please use evolution[composer] and > > evolution[webkit] whiteboards. > > I plan to create gnome-3-6 branches after the 3.5.92 release later this > month. We can merge immediately after to give as much testing time as > possible. That would be great. Hopefully I'll be able to port the signatures until then. Cheers, Dan -- dvra...@redhat.com | Associate Software Engineer / BaseOS / KDE, Qt GPG Key: 0xC59D614F6F4AE348 Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
