How to draw a TreeView row select bar from a png file?
Hi,all The TreeView row select bar seem to be draw with the treeview base[SELECTED] color? but I want to draw the bar from a image file? Thanks! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Unregister a GType
Hi list, I'm developing an application with plugin support. One of the plugins registers a GType (EinaAdb) but if I load, unload, and finally reload it I get some messages and my app crashes or freezes. Messages are: (eina:28412): GLib-GObject-WARNING **: cannot register existing type `EinaAdb' (eina:28412): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (eina:28412): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed I understand why this messages appear: I'm registering a GType when the plugin is initialized, after reloading it I'm re-registering an existing type, obviously it fails. The question is: there is any way to unregister a type or its imposible for a loadable module to register new types? Thanks! PD. Code can be found at: http://github.com/xuzo/eina/blob/plugin-subsystem/plugins/adb/eina-adb.c ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Multi-platform dbus (was: Ige-mac-integration: New version with Cocoa interface available)
Sorry for my naivete
But I have been building some of our application tool sets in native Cocoa (the
printing industry is exclusively MAC, with little room for anything else).
The question being, in the standard Cocoa application framework you never
actually derive the NSApplication class, but instead you derive the
NSApplicationDelegate. Would this not be more appropriate for this discussion.
It receive all the signals for each interface object whos IBoutlet is set to
this class, and all the functionality for the toolbar, menu, etc, is exposed in
it.
IE this class actually receives the signal for the NSSearchField object, and
process it. So should GTKApplication.c not really be GTKApplicationDelegate.c,
or perhaps both.
Last I recall of the MFC, there was something similar where you had a
CCmdTarget which did a lot of what I guess GTKApplication.C is todo, but seems
more inline with NSApplicationDelegate than NSApplication.
I've noticed a lot of stuff like GTKTreeView implement its own displays, why is
it not derived from NSTableView using NSDataSource for GTKTreeStore and
GTKListStore? Or is the point to also make it all look alike?
-- MY APP DELIGATIONS
@interface isiod2AppDelegate : NSObject {
/*Views */
NSWindow *window;
AnalyzerView *view;
SimpleCView *scView;
/* Fields */
NSSearchField *searchField;
NSTextField *startDate;
NSTextField * endDate;
/* Tables */
NSTableView *shippingTable;
NSTableView *receivingTable;
NSTableView *batchesTable;
NSTableView *usageTable;
/* Data sources */
isilistDataSource *shippingDS;
isilistDataSource *receivingDS;
isilistDataSource *batchesDS;
isilistDataSource *usageDS;
/* Internal objects */
IsiComponent *component;
IsiDatabase *db;
}
/* Views */
@property (assign) IBOutlet NSWindow *window;
@property (assign) IBOutlet AnalyzerView *view;
@property (assign) IBOutlet SimpleCView *scView;
/* Fields */
@property (assign) IBOutlet NSSearchField *searchField;
@property (assign) IBOutlet NSTextField * startDate;
@property (assign) IBOutlet NSTextField * endDate;
/* Tables */
@property (assign) IBOutlet NSTableView *shippingTable;
@property (assign) IBOutlet NSTableView *receivingTable;
@property (assign) IBOutlet NSTableView *batchesTable;
@property (assign) IBOutlet NSTableView *usageTable;
/* Actions */
- (IBAction)filterSearch:(id)sender;
@end
> Subject: Re: Multi-platform dbus (was: Ige-mac-integration: New version with
> Cocoa interface available)
> From: jra...@ceridwen.us
> Date: Tue, 18 May 2010 14:10:22 -0700
> To: p...@linuxaudiosystems.com
> CC: gtk-devel-l...@gnome.org
>
>
> On May 18, 2010, at 1:36 PM, Paul Davis wrote:
>
> >
> >
> > On Tue, May 18, 2010 at 4:12 PM, John Ralls wrote:
> >
> > Sure. But dbus provides services which are provided by notifications and
> > AppleEvents on OSX. If a supposedly cross-platform application supports
> > only the dbus way, it turns out to be pretty autistic on OSX. I don't think
> > that it's all that common for OSX users (aside from the few Fink and
> > MacPorts users who are trying to replicate an entire Linux environement) to
> > run more than one or two dbus-using apps, and they aren't able to
> > communicate with other OSX application or OSX itself unless those channels
> > are separately implemented.
> >
> > So maybe g_dbus isn't the right place for the abstraction layer; it could
> > be one of the implementation layers.
> >
> > i think that is precisely what is being proposed:
> > GApplication/GtkApplication as the abstaction that covers notifications
> > etc, and an implementation for a given platform. the linux/X11/FD.org one
> > would use DBus. apps that choose to use DBus directly will be assumed to
> > want something specific that DBus offers, and not a generic
> > platform-agnostic "application abstraction".
>
> OK.
>
> I don't think that GApplication is a good name for it, though. The fact that
> some notifications (became active, quit, etc.) are directed at the
> application object doesn't mean that all of them should be.
>
> Regards,
> John Ralls
> ___
> gtk-devel-list mailing list
> gtk-devel-l...@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
_
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi-platform dbus (was: Ige-mac-integration: New version with Cocoa interface available)
On Thu, May 20, 2010 at 3:56 PM, Shawn Bakhtiar wrote:
>
> Sorry for my naivete
>
> But I have been building some of our application tool sets in native Cocoa
> (the printing industry is exclusively MAC, with little room for anything
> else).
>
> The question being, in the standard Cocoa application framework you never
> actually derive the NSApplication class, but instead you derive the
> NSApplicationDelegate. Would this not be more appropriate for this
> discussion. It receive all the signals for each interface object whos
> IBoutlet is set to this class, and all the functionality for the toolbar,
> menu, etc, is exposed in it.
Shawn,
Maybe I'm misreading you but are you suggesting that GTK+ should
export proxy interfaces
to be signalled by an internal GtkApplication in the code ? (i.e.
applications would set the core's
application delagate object ?).
Personally I would much rather avoid that api and have the osx
implementation of GtkApplication
assign a delegate internally if it needs to; and in this way export
IMO a saner api than Cocoa does.
Cocoa may have a specific reason why they had to add a delegate object
separate to the app
object (maybe something tied to springboard...)
Or maybe it is their preference to export such an api, i.e. see
UIViewController vs. NSView
(there is also no reason here I can see why one would rather implement
a controller proxy
than to implement the parent view, although I suspect this restriction
is mearly imposed by
the way they chose to implement nib files with Interface Builder).
Best Regards,
-Tristan
>
> IE this class actually receives the signal for the NSSearchField object, and
> process it. So should GTKApplication.c not really be
> GTKApplicationDelegate.c, or perhaps both.
>
> Last I recall of the MFC, there was something similar where you had a
> CCmdTarget which did a lot of what I guess GTKApplication.C is todo, but
> seems more inline with NSApplicationDelegate than NSApplication.
>
> I've noticed a lot of stuff like GTKTreeView implement its own displays, why
> is it not derived from NSTableView using NSDataSource for GTKTreeStore and
> GTKListStore? Or is the point to also make it all look alike?
>
>
> -- MY APP DELIGATIONS
> @interface isiod2AppDelegate : NSObject {
>
> /*Views */
> NSWindow *window;
> AnalyzerView *view;
> SimpleCView *scView;
>
> /* Fields */
> NSSearchField *searchField;
> NSTextField *startDate;
> NSTextField * endDate;
>
> /* Tables */
> NSTableView *shippingTable;
> NSTableView *receivingTable;
> NSTableView *batchesTable;
> NSTableView *usageTable;
>
>
> /* Data sources */
> isilistDataSource *shippingDS;
> isilistDataSource *receivingDS;
> isilistDataSource *batchesDS;
> isilistDataSource *usageDS;
>
> /* Internal objects */
> IsiComponent *component;
> IsiDatabase *db;
>
> }
>
> /* Views */
> @property (assign) IBOutlet NSWindow *window;
> @property (assign) IBOutlet AnalyzerView *view;
> @property (assign) IBOutlet SimpleCView *scView;
>
> /* Fields */
> @property (assign) IBOutlet NSSearchField *searchField;
> @property (assign) IBOutlet NSTextField * startDate;
> @property (assign) IBOutlet NSTextField * endDate;
>
>
> /* Tables */
> @property (assign) IBOutlet NSTableView *shippingTable;
> @property (assign) IBOutlet NSTableView *receivingTable;
> @property (assign) IBOutlet NSTableView *batchesTable;
> @property (assign) IBOutlet NSTableView *usageTable;
>
>
>
> /* Actions */
> - (IBAction)filterSearch:(id)sender;
>
> @end
>
>
>
>
>
>> Subject: Re: Multi-platform dbus (was: Ige-mac-integration: New version with
>> Cocoa interface available)
>> From: jra...@ceridwen.us
>> Date: Tue, 18 May 2010 14:10:22 -0700
>> To: p...@linuxaudiosystems.com
>> CC: gtk-devel-l...@gnome.org
>>
>>
>> On May 18, 2010, at 1:36 PM, Paul Davis wrote:
>>
>> >
>> >
>> > On Tue, May 18, 2010 at 4:12 PM, John Ralls wrote:
>> >
>> > Sure. But dbus provides services which are provided by notifications and
>> > AppleEvents on OSX. If a supposedly cross-platform application supports
>> > only the dbus way, it turns out to be pretty autistic on OSX. I don't
>> > think that it's all that common for OSX users (aside from the few Fink and
>> > MacPorts users who are trying to replicate an entire Linux environement)
>> > to run more than one or two dbus-using apps, and they aren't able to
>> > communicate with other OSX application or OSX itself unless those channels
>> > are separately implemented.
>> >
>> > So maybe g_dbus isn't the right place for the abstraction layer; it could
>> > be one of the implementation layers.
>> >
>> > i think that is precisely what is being proposed:
>> > GApplication/GtkApplication as the abstaction that covers notifications
>> > etc, and an implementation for a given platform. the linux/X11/FD.org one
>> > would use DBus. apps that choose to use DBus directly will be assumed to
>> > want something specific that
