From gambas at ...1... Wed Jan 2 17:21:18 2013 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Wed, 02 Jan 2013 17:21:18 +0100 Subject: [Gambas-devel] Flaw in GTK+ 2 / 3 Message-ID: <50E45E7E.4000400@...1...> Hi, Since a few revision, all drawings are done in gb.gtk with cairo ; as requested by GTK+, which has deprecated the old drawing API. Fine. But there is a problem with images. Images in GTK+ are managed by the GdkPixbuf class, which stores the image data in memory with the RGBA format. (As x86 is little endian, in memory you have actually R-G-B-A, and if you read it as a 32 bits integer, R is in the lowest bits and A in the highest). But Cairo only handles images in the pre-multiplied BGRP format (like Qt4). So each time you call Draw.Image() or Paint.DrawImage(), a costly conversion is needed. I'm currently searching for some sort of workaround for this design flaw in GTK+. That flaw has not been fixed in GTK+ 3 apparently. Why didn't they change GdkPixbuf so that it uses the same format as Cairo, or why didn't they deprecated GdkPixbuf for a new image class using that format? That is the question... Any suggestion is welcome! -- Beno?t Minisini From gambas at ...1... Wed Jan 2 20:04:21 2013 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Wed, 02 Jan 2013 20:04:21 +0100 Subject: [Gambas-devel] Flaw in GTK+ 2 / 3 In-Reply-To: <50E45E7E.4000400@...1...> References: <50E45E7E.4000400@...1...> Message-ID: <50E484B5.1000007@...1...> Le 02/01/2013 17:21, Beno?t Minisini a ?crit : > Hi, > > Since a few revision, all drawings are done in gb.gtk with cairo ; as > requested by GTK+, which has deprecated the old drawing API. > > Fine. But there is a problem with images. > > Images in GTK+ are managed by the GdkPixbuf class, which stores the > image data in memory with the RGBA format. (As x86 is little endian, in > memory you have actually R-G-B-A, and if you read it as a 32 bits > integer, R is in the lowest bits and A in the highest). > > But Cairo only handles images in the pre-multiplied BGRP format (like Qt4). > > So each time you call Draw.Image() or Paint.DrawImage(), a costly > conversion is needed. > > I'm currently searching for some sort of workaround for this design flaw > in GTK+. > > That flaw has not been fixed in GTK+ 3 apparently. Why didn't they > change GdkPixbuf so that it uses the same format as Cairo, or why didn't > they deprecated GdkPixbuf for a new image class using that format? That > is the question... > > Any suggestion is welcome! > More details there: https://live.gnome.org/GtkCairoIntegration -- Beno?t Minisini From gambas at ...1... Sat Jan 5 10:46:37 2013 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 05 Jan 2013 10:46:37 +0100 Subject: [Gambas-devel] Bug detected in gb.data Message-ID: <50E7F67D.9040209@...1...> Hi, Tobias. The Coverity Scan software has detected the following problem in gb.data : The following function in 'c_list.c' is incorrect: static inline int VAL_is_valid(VAL *val) { int i = val->fidx + val->ck->first; int j = val->lidx + val->ck->last; if (i != j || !val->ck || val->fidx == -1 || i > val->ck->last) return 0; return 1; } because 'val->ck->first' is accessed before being null-checked. I don't know if it is problematic, but it seems. Can you check that? Thanks! -- Beno?t Minisini From emil.lenngren at ...176... Sat Jan 5 14:33:36 2013 From: emil.lenngren at ...176... (Emil Lenngren) Date: Sat, 5 Jan 2013 14:33:36 +0100 Subject: [Gambas-devel] Bug detected in gb.data In-Reply-To: <50E7F67D.9040209@...1...> References: <50E7F67D.9040209@...1...> Message-ID: That function is never called... 2013/1/5 Beno?t Minisini > Hi, Tobias. > > The Coverity Scan software has detected the following problem in gb.data : > > The following function in 'c_list.c' is incorrect: > > static inline int VAL_is_valid(VAL *val) > { > int i = val->fidx + val->ck->first; > int j = val->lidx + val->ck->last; > > if (i != j || !val->ck || val->fidx == -1 || i > val->ck->last) > return 0; > return 1; > } > > because 'val->ck->first' is accessed before being null-checked. > > I don't know if it is problematic, but it seems. Can you check that? > > Thanks! > > -- > Beno?t Minisini > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122912 > _______________________________________________ > Gambas-devel mailing list > Gambas-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias at ...692... Sat Jan 5 15:34:29 2013 From: tobias at ...692... (Tobias Boege) Date: Sat, 5 Jan 2013 15:34:29 +0100 Subject: [Gambas-devel] Bug detected in gb.data In-Reply-To: References: <50E7F67D.9040209@...1...> Message-ID: <20130105143428.GA726@...693...> On Sat, 05 Jan 2013, Emil Lenngren wrote: > That function is never called... > > 2013/1/5 Beno?t Minisini > > > Hi, Tobias. > > > > The Coverity Scan software has detected the following problem in gb.data : > > > > The following function in 'c_list.c' is incorrect: > > > > static inline int VAL_is_valid(VAL *val) > > { > > int i = val->fidx + val->ck->first; > > int j = val->lidx + val->ck->last; > > > > if (i != j || !val->ck || val->fidx == -1 || i > val->ck->last) > > return 0; > > return 1; > > } > > > > because 'val->ck->first' is accessed before being null-checked. > > > > I don't know if it is problematic, but it seems. Can you check that? > > > > Thanks! This fact would indeed be problematic according to the function's semantics but Emil is right, it's not used anywhere. OK, that's embarrassing :-) Removed in rev#5491. I checked that file again and this seems to have been the only unused function (must have been a leftover or so). Thanks, Tobi From gambas at ...1... Sat Jan 26 11:55:03 2013 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 26 Jan 2013 11:55:03 +0100 Subject: [Gambas-devel] [Gambas-user] Expander on FPatch in the IDE In-Reply-To: <20130125232156.GF844@...693...> References: <20130125232156.GF844@...693...> Message-ID: <5103B607.1020601@...1...> Le 26/01/2013 00:21, Tobias Boege a ?crit : > Hi Benoit, > > when I click on the Expander in the FPatch form in the IDE, I just added, > the IDE crashes with a Null object in FSidePanel. I think it's your turn :-) > > Regards, > Tobi > Which expander ? -- Beno?t Minisini From gambas at ...1... Sat Jan 26 12:01:38 2013 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sat, 26 Jan 2013 12:01:38 +0100 Subject: [Gambas-devel] [Gambas-user] Expander on FPatch in the IDE In-Reply-To: <5103B607.1020601@...1...> References: <20130125232156.GF844@...693...> <5103B607.1020601@...1...> Message-ID: <5103B792.7080101@...1...> Le 26/01/2013 11:55, Beno?t Minisini a ?crit : > Le 26/01/2013 00:21, Tobias Boege a ?crit : >> Hi Benoit, >> >> when I click on the Expander in the FPatch form in the IDE, I just added, >> the IDE crashes with a Null object in FSidePanel. I think it's your turn :-) >> >> Regards, >> Tobi >> > > Which expander ? > > By the way, the interface of your patching system is not good: - The "Generate"->"Patch" should open a wizard. You must not successively open two file selectors, because the user does not see every step of the process and cannot go back. - "Patching" in the "Generate" menu entry??? You should have put it in the Project menu entry. Nothing is generated there. - You should be able to create a patch from an existing project (for example if you have two different versions of the project on the disk), not just from a source archive. - You must ignore the subversion files and the backup files of the new project when creating the patch! Eventually by doing a temporary source archive of the new project and create the patch from it. I didn't test the patch dialog yet, I will have other comments for sure! :-) Regards, -- Beno?t Minisini From tobias at ...692... Sat Jan 26 13:14:53 2013 From: tobias at ...692... (Tobias Boege) Date: Sat, 26 Jan 2013 13:14:53 +0100 Subject: [Gambas-devel] [Gambas-user] Expander on FPatch in the IDE In-Reply-To: <5103B607.1020601@...1...> References: <20130125232156.GF844@...693...> <5103B607.1020601@...1...> Message-ID: <20130126121453.GC651@...693...> On Sat, 26 Jan 2013, Beno?t Minisini wrote: > Le 26/01/2013 00:21, Tobias Boege a ?crit : > > Hi Benoit, > > > > when I click on the Expander in the FPatch form in the IDE, I just added, > > the IDE crashes with a Null object in FSidePanel. I think it's your turn :-) > > > > Regards, > > Tobi > > > > Which expander ? > Excuse me, it once was an Expander but I switched to a SidePanel, on FPatch. From gambas at ...1... Sun Jan 27 16:10:51 2013 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 27 Jan 2013 16:10:51 +0100 Subject: [Gambas-devel] [Gambas-user] Expander on FPatch in the IDE In-Reply-To: <20130126121453.GC651@...693...> References: <20130125232156.GF844@...693...> <5103B607.1020601@...1...> <20130126121453.GC651@...693...> Message-ID: <5105437B.70700@...1...> Le 26/01/2013 13:14, Tobias Boege a ?crit : > On Sat, 26 Jan 2013, Beno?t Minisini wrote: >> Le 26/01/2013 00:21, Tobias Boege a ?crit : >>> Hi Benoit, >>> >>> when I click on the Expander in the FPatch form in the IDE, I just added, >>> the IDE crashes with a Null object in FSidePanel. I think it's your turn :-) >>> >>> Regards, >>> Tobi >>> >> >> Which expander ? >> > > Excuse me, it once was an Expander but I switched to a SidePanel, on FPatch. > The SidePanel crash should be fixed in the last revision. Anyway, you don't use it correctly (the layout of the other dialog controls must expand when the SidePanel is hidden), and the FPatch dialog design should be fixed (too small buttons, the dialog is not modal...) I have fixed a few things in the FMakePatch wizard design too (removing as much borders as possible). I noticed that you used an hack to select the "old" project: you took a DirChooser, and checked that a file has been selected inside the DirChooser to decide if the user want to generate a patch from a project archive or a project directory. I'm not sure this is a good idea, and I think that a more explicit interface would be better (even if a bit stupid). I mean: let the user explicitely decide if he wants to start with an archive or a project directory, and then let it use a FileChooser in the first case, and a DirChooser in the other case. As for selecting a project directory (second case), there is the code located in the FOpenProject dialog, but it must be factorized in some sort of "ProjectChooser" control. I will try to do it so that you can use it. There are other things to fix in the dialog: some message are not translated ; if you select nothing in the wizard second step, you get a strange error instead of just a warning telling you that you must select something. Regards, -- Beno?t Minisini From tobias at ...692... Sun Jan 27 17:50:33 2013 From: tobias at ...692... (Tobias Boege) Date: Sun, 27 Jan 2013 17:50:33 +0100 Subject: [Gambas-devel] [Gambas-user] Expander on FPatch in the IDE In-Reply-To: <5105437B.70700@...1...> References: <20130125232156.GF844@...693...> <5103B607.1020601@...1...> <20130126121453.GC651@...693...> <5105437B.70700@...1...> Message-ID: <20130127165033.GB670@...693...> On Sun, 27 Jan 2013, Beno?t Minisini wrote: > The SidePanel crash should be fixed in the last revision. Anyway, you > don't use it correctly (the layout of the other dialog controls must > expand when the SidePanel is hidden), and the FPatch dialog design > should be fixed (too small buttons, the dialog is not modal...) > > I have fixed a few things in the FMakePatch wizard design too (removing > as much borders as possible). > The collapse thing works now: all other controls are enlarged. But the Editor isn't resized anymore with the window. I couldn't figure out a way to have both features... > I noticed that you used an hack to select the "old" project: you took a > DirChooser, and checked that a file has been selected inside the > DirChooser to decide if the user want to generate a patch from a project > archive or a project directory. > > I'm not sure this is a good idea, and I think that a more explicit > interface would be better (even if a bit stupid). > > I mean: let the user explicitely decide if he wants to start with an > archive or a project directory, and then let it use a FileChooser in the > first case, and a DirChooser in the other case. > > As for selecting a project directory (second case), there is the code > located in the FOpenProject dialog, but it must be factorized in some > sort of "ProjectChooser" control. I will try to do it so that you can > use it. > OK. But I have no idea how to design the explicit decision aesthetically. I can't just throw two RadioButtons to the top of the Form, right? > There are other things to fix in the dialog: some message are not > translated ; if you select nothing in the wizard second step, you get a > strange error instead of just a warning telling you that you must select > something. > They are warnings now. I found one string and marked it translatable. What do you say about the /tmp/gambas-patch-ignore file (Patch.class)? Better than having a dozen "-x ..." in the patch file, I think. Regards, Tobi From tobias at ...692... Sun Jan 27 21:38:29 2013 From: tobias at ...692... (Tobias Boege) Date: Sun, 27 Jan 2013 21:38:29 +0100 Subject: [Gambas-devel] [Gambas-user] Expander on FPatch in the IDE In-Reply-To: <5105437B.70700@...1...> References: <20130125232156.GF844@...693...> <5103B607.1020601@...1...> <20130126121453.GC651@...693...> <5105437B.70700@...1...> Message-ID: <20130127203829.GC670@...693...> On Sun, 27 Jan 2013, Beno?t Minisini wrote: > As for selecting a project directory (second case), there is the code > located in the FOpenProject dialog, but it must be factorized in some > sort of "ProjectChooser" control. I will try to do it so that you can > use it. I don't understand the FOpenProject sources anymore now :-) pchProject is a DrawingArea that behaves like a ProjectChooser? Nevertheless, here's what I observed: - FOpenProject: One cannot open a project by double-clicking on it in the ProjectChooser anymore. I miss that. - ProjectChooser: Can't we hard-code a "*.tar.{gz,bz2,xz}" filter in the file part of the chooser to only display source archives? There is a lot of unrelated stuff displayed. I prefer wait with my changes until these points are clear. Regards, Tobi From gambas at ...1... Sun Jan 27 21:46:07 2013 From: gambas at ...1... (=?ISO-8859-1?Q?Beno=EEt_Minisini?=) Date: Sun, 27 Jan 2013 21:46:07 +0100 Subject: [Gambas-devel] [Gambas-user] Expander on FPatch in the IDE In-Reply-To: <20130127203829.GC670@...693...> References: <20130125232156.GF844@...693...> <5103B607.1020601@...1...> <20130126121453.GC651@...693...> <5105437B.70700@...1...> <20130127203829.GC670@...693...> Message-ID: <5105920F.9030203@...1...> Le 27/01/2013 21:38, Tobias Boege a ?crit : > On Sun, 27 Jan 2013, Beno?t Minisini wrote: >> As for selecting a project directory (second case), there is the code >> located in the FOpenProject dialog, but it must be factorized in some >> sort of "ProjectChooser" control. I will try to do it so that you can >> use it. > > I don't understand the FOpenProject sources anymore now :-) pchProject is a > DrawingArea that behaves like a ProjectChooser? No, pchProject is a ProjectChooser control. > > Nevertheless, here's what I observed: > - FOpenProject: One cannot open a project by double-clicking on it in the > ProjectChooser anymore. I miss that. Yep, I forgot to handle the "Activate" event of the ProjectChooser control. I will fix that. > - ProjectChooser: Can't we hard-code a "*.tar.{gz,bz2,xz}" filter in the > file part of the chooser to only display source archives? There is a lot > of unrelated stuff displayed. ProjectChooser is for selecting project. For selecting archives, you must use a FileChooser with a filter. Yes, you should put two radio buttons to let the user choose if he wants to select a project or a source archive, and then display the corresponding chooser control. You can even create four steps in your wizard: - The first one will allow to just select between project or archive. - The second step will select a project and will be disabled (MyWizard[1].Enabled = False) if the user want to select an archive. - The third step will select an archive and will be disabled if the user want to select a project. - The fourth step is your old second step. The wizard automatically skips disabled steps. Regards, -- Beno?t Minisini From tobias at ...692... Tue Jan 29 22:21:01 2013 From: tobias at ...692... (Tobias Boege) Date: Tue, 29 Jan 2013 22:21:01 +0100 Subject: [Gambas-devel] [Gambas-user] Expander on FPatch in the IDE In-Reply-To: <5105920F.9030203@...1...> References: <20130125232156.GF844@...693...> <5103B607.1020601@...1...> <20130126121453.GC651@...693...> <5105437B.70700@...1...> <20130127203829.GC670@...693...> <5105920F.9030203@...1...> Message-ID: <20130129212101.GB603@...693...> On Sun, 27 Jan 2013, Beno?t Minisini wrote: > Le 27/01/2013 21:38, Tobias Boege a ?crit : > > On Sun, 27 Jan 2013, Beno?t Minisini wrote: > >> As for selecting a project directory (second case), there is the code > >> located in the FOpenProject dialog, but it must be factorized in some > >> sort of "ProjectChooser" control. I will try to do it so that you can > >> use it. > > > > I don't understand the FOpenProject sources anymore now :-) pchProject is a > > DrawingArea that behaves like a ProjectChooser? > > No, pchProject is a ProjectChooser control. > Yes, very strange... My unpacked sources say it's a DrawingArea - the .form file, too! The original archive still says it's a ProjectChooser... Both projects work at run-time. However, I changed it back and everything is well. > You can even create four steps in your wizard: > - The first one will allow to just select between project or archive. > - The second step will select a project and will be disabled > (MyWizard[1].Enabled = False) if the user want to select an archive. > - The third step will select an archive and will be disabled if the user > want to select a project. > - The fourth step is your old second step. > > The wizard automatically skips disabled steps. It is done like this now. I wonder if there was a simpler way of centering controls than surrounding them will all kinds of boxes. See step #1 in the wizard... While we are at it: don't these Radiobuttons look very lonesome? Regards, Tobi