Re: 16 bits grayscale images
--- alex [EMAIL PROTECTED] wrote: Hello list, I want to create a grayscale image from a CCD camera. Data are from a function wich gives me an 16 bits array corresponding to the CCD's pixels. I take a look at the pixbuf class, but it seems to use a RGB structure. How can I do my job ? Thanks in advance. ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list You might think about using ImageMagick, which is a different list :-). I am not sure gtk+ is 16 bits per pixel per color friendly, I think it assumes 8 bits, otherwise we all would have already seen 16 bits per color per pixel in GIMP. Regards, Sergei. Applications From Scratch: http://appsfromscratch.berlios.de/ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: 16 bits grayscale images
--- David Neèas (Yeti) [EMAIL PROTECTED] wrote: On Thu, Sep 27, 2007 at 04:45:10PM +0200, alex wrote: I want to create a grayscale image from a CCD camera. Data are from a function wich gives me an 16 bits array corresponding to the CCD's pixels. I take a look at the pixbuf class, but it seems to use a RGB structure. How can I do my job ? If you don't expect the graphics system to be actually capable of displaying 16bpc images, it is easiest to just convert the data to 8bpp RGB (which is a trivial operation). Yeti -- http://gwyddion.net/ ___ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list Oh, I expect a lot of things. And I do not consider a lot of things to be trivial. First of all, modern displays have contrast ratios greater than 255:1, so there is no physical reason not expect more than 8 bits of dynamic range, and, actually, even with smaller contrast ratios the matter is brighness resolution. Second, 16 - 8 bits conversion is not trivial - I am not talking about taking just, say, upper 8 bits of a 16 bits word. I am talking about brightness compression first. For example, I can decide to use 12 bits of dynamic range of input image, then convert them to 8 bits using something gamma-like curve, i.e. mapping function, changing the curve steepness as needed for my image, for example, increasing it in lower values range if I want to show shadow details. ... Remember, KDE's KRITA uses ImageMagic for a reason; ImageMagic supports up to floating point number per color per pixel IIRC. Regards, Sergei. Applications From Scratch: http://appsfromscratch.berlios.de/ Need a vacation? Get great deals to amazing places on Yahoo! Travel. http://travel.yahoo.com/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Theory of good signal/event API design?
On Sun, 2007-09-16 at 18:28 +0200, Sander Marechal wrote: My question: How do I determine what signals/events I should send out so that together they make for a nice module API? For now, I am simply building modules and adding signals to the application as I need them, but I bet there is a better way to figure out which signals I should add and where I should add them. You can think of signals in different ways: * Something happened - an informational message. Oh, the Loader object said 'finished', so it's done. You'd then process the loaded data or something. * I need something from somewhere - an actual request that must be handled. Oh, the HTMLWidget said 'load-image' and gave me a URI, so I guess I should download that image and feed it to the widget. * Something bad happened - an error in an object that handles a long-running process. Oh, the ImageDecoder emitted 'error' with a CORRUPTED_DATA argument, so that image file must be broken. * etc. So you can have signals that are hooks for expansion, actual requests for information, simple notifications, etc. One big thing to think about when you have signals is whether your object should be reentrant. What happens if someone calls a method on your object from a signal handler for that object? Should the object support it or not? Does it need to support at least minimal reentrancy (e.g. to let you call foo_delete_item() when you are inside a foo::item_inserted signal handler)? Federico ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to set the window size to max height, but not the max width?
Hello Gtk+ Mailling Lists: I'm a beginner of GTK+ Development. I want my application run like this: when it opens, the window's width is set to 1024, and its height will be set to the current available max height size. It's not the size of resolution of current screen. Just the maximize window's height, the size not include the two gnome-panel below and above, sometimes is a dock(awn or kiba-dock). I tried several method, but failed. Anyone can give me an idea? Thank you very much. -- GTALK: [EMAIL PROTECTED] ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gcolorsel-2.0 released
Ian I just uploaded a tarball of gcolorsel-2.0.1, the enhanced gtk-2.x Ian color selector, to Ian http://primate.net/~itz/gcolorsel/ That location has now changed to http://madbat.mine.nu/public/gcolorsel/ There is a redirect in effect for now, but it won't be there forever. Enjoy, Ian. -- This line is completely ham. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Auto-scrolling the scrollbar on a TreeView
Hi, The behavior you want should happen automatically - works for me. Certain widgets, like the TreeView and the TextView understand if they are nested within a scrolled window and scroll automatically when needed. Probably there is something wrong with the way you set up the scrolled window and the treeview together. The link you give does not work, so I can not check your code. Regards, Jaap From: [EMAIL PROTECTED] on behalf of Rob Hoelz Sent: Wed 10/3/2007 1:29 AM To: gtk-app-devel-list@gnome.org; [EMAIL PROTECTED] Subject: Auto-scrolling the scrollbar on a TreeView Hello everyone, I'm currently using a Gtk2 TreeView within a Gtk2 ScrolledWindow, and I'd like to be able to navigate the tree using the keyboard. I've set up key bindings so Right expands a tree, Left collapses it, and Up and Down seem to be already set to navigate expanded cells. However, when I use Down to navigate to a cell off-screen, I'd like the ScrolledWindow to compensate. I've tried scroll_to_cell, but to no avail. Any hints? I've posted the source code at http://cs.wisc.edu/~hoelz/TodoList.pl; the problem is in the callback at line 157. Thanks, Rob Hoelz ___ gtk-perl-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-perl-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Spontaneous background colors in treeview
Hi, On Mon, Oct 01, 2007 at 11:30:58AM -0600, Jeffrey Barish wrote: Stop presses. It's the number of columns. All data sets that require 3 columns have a background. All data sets that require 2 columns do not. Here it is. If I comment out the line that sets the sort indicator, I do not get the colored background for any data set. I thought you meant the rows had alternating background colors in your previous mails. When you sort a column in a tree view with = 3 columns, the sorted column is drawn with a background that is slightly darker than the default background (in the default theme it is a shade of grey). This is the default and correct behavior. regards, -kris. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Auto-scrolling the scrollbar on a TreeView
Hi, On Tue, Oct 02, 2007 at 06:29:31PM -0500, Rob Hoelz wrote: ScrolledWindow to compensate. I've tried scroll_to_cell, but to no avail. Any hints? I've posted the source code at http://cs.wisc.edu/~hoelz/TodoList.pl; the problem is in the callback at line 157. Both GtkTreeView and GtkTextView have native scrolling capabilities, so you should be using the add method on the scrolled window instead of add_with_viewport. If I replace $topScroll-add_with_viewport ($top); with $topScroll-add ($top); in your code then navigating from item to item with the keyboard will scroll the tree view correctly here. regards, -kris. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GnomeVFS, gvfs, and FUSE
I have been reading that GnomeVFS should be avoided in the future. I have a GNOME application which works on text files opened locally or remotely via FTP and SSH using GnomeVFS. Should I move towards other options, such as FUSE? Is GVFS going to be the next GnomeVFS? -- - Micah Carrick Developer - http://www.micahcarrick.com GTK+ Forums - http://www.gtkforums.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: timeout function not called
On Tue, 2007-10-02 at 10:51 -0400, [EMAIL PROTECTED] wrote:
I'm still muddling my way through my first GTK application (and I'm a
relative newbie on all software matters).
I have the following in one of my callbacks:
timer = g_timout_add(50, (GSourceFunc) progress_update,
(gpointer)progressbar);
pid = fork( );
if (pid == 0)
{
growPart ( );
exit(0);
}
ret = wait(NULL);
g_source_remove(timer);
---
where progress_update is:
static gboolean progress_update (gpointer progressbar)
{
gtk_progress_bar_pulse(GTK_PROGRESS_BAR(progressbar));
return true;
}
I was hoping that this would mean that the progress bar would pulse while
growPart() was running, but instead it waits until after (is this because
control hasn't been returned to gtk_main yet?) at which point it is
removed. If I take out the g_source_remove it runs beautifullybut only
after growPart has completed. How can I get around this?
Thanks so much
The use of FORK is a little odd, I don't think I've seen that used in a
GTK program before. The ret=wait(null) causes execution to stop at that
point and wait for growPart() to finish. A way to get around the
logistics of fork() is to use threads directly. Consider the following;
/* globals */
gboolean b_pulse_control = FALSE
GThread *grow_thread_id = NULL;
gint global_ret = 0;
b_pulse_control = TRUE;
timer = g_timeout_add(50, (GSourceFunc) progress_update,
(gpointer)progressbar);
grow_thread_id = g_thread_create ( growPart_thread, b_pulse_control,
TRUE, NULL);
static gboolean progress_update (gpointer progressbar)
{
if (b_pulse_control)
{
gtk_progress_bar_pulse(GTK_PROGRESS_BAR(progressbar));
return true;
} else {
global_ret = GPOINTER_TO_INT( g_thread_join (grow_thread) );
return FALSE;
}
}
static gpointer growPart_thread(gpointer b_pulse)
{
/* do work */
growPart();
*b_pulse = FALSE;
g_thread_exit( GINT_TO_POINTER( 1 ) );
}
I would do the passing of control values via a structure to avoid the use of
globals, but this should work for you.
James,
This is an e-mail from General Dynamics Land Systems. It is for the intended
recipient only and may contain confidential and privileged information. No
one else may read, print, store, copy, forward or act in reliance on it or
its attachments. If you are not the intended recipient, please return this
message to the sender and delete the message and any attachments from your
computer. Your cooperation is appreciated.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Spontaneous background colors in treeview
Kristian Rietveld wrote: Hi, On Mon, Oct 01, 2007 at 11:30:58AM -0600, Jeffrey Barish wrote: Stop presses. It's the number of columns. All data sets that require 3 columns have a background. All data sets that require 2 columns do not. Here it is. If I comment out the line that sets the sort indicator, I do not get the colored background for any data set. I thought you meant the rows had alternating background colors in your previous mails. When you sort a column in a tree view with = 3 columns, the sorted column is drawn with a background that is slightly darker than the default background (in the default theme it is a shade of grey). This is the default and correct behavior. I did mean the rows. With 3 columns (or more, perhaps -- my data sets never require more than 3 so I don't know) and with set sort indicator set to true, I get alternating *rows* of color. With 2 columns and with set sort indicator set to true, the background is white. With set sort indicator set to false, the background is white for any number of columns. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
