From: Sean E. <sea...@gm...> - 2006-06-23 18:01:13
|
Hey guys, Now that we're in svn, and new development, especially that by Adil, seems to promote it, I think we should probably restructure our source tree. How does this look: gaim core protocols gtk console plugins -s |
From: Gary K. <gr...@re...> - 2006-06-23 18:04:18
|
Sean Egan wrote: > Hey guys, > > Now that we're in svn, and new development, especially that by Adil, > seems to promote it, I think we should probably restructure our source > tree. How does this look: > > gaim > core > protocols > gtk > console > plugins > > -s Sounds good to me. I can make this happen when working on sadrul's core/ui build targets patch next week to. Since that'll make the patch a bit easier to finish up. -- Gary Kramlich <gr...@re...> |
From: Etan R. <de...@ed...> - 2006-06-23 18:06:07
|
On Fri, 23 Jun 2006, Sean Egan wrote: > Hey guys, > > Now that we're in svn, and new development, especially that by Adil, > seems to promote it, I think we should probably restructure our source > tree. How does this look: > > gaim > core > protocols > gtk > console > plugins > > -s Looks fine to me, though maybe we want to split plugins into core/gtk/console as well. Either by making core/gtk/console directories under plugins/ or by splitting plugins/ up under the proposed core/gtk/console. -Etan |
From: Mark D. <ma...@ki...> - 2006-06-23 18:19:01
|
On Fri, 23 Jun 2006 11:01:12 -0700, Sean Egan wrote > Hey guys, > > Now that we're in svn, and new development, especially that by Adil, > seems to promote it, I think we should probably restructure our > source tree. How does this look: > > gaim > core > protocols > gtk > console > plugins All the configure stuff, README, COPYRIGHT, etc. would go directly in the 'gaim' directory, I guess? That sounds good to me. And I'd be ok with splitting the plugins into core/gtk/console directory, too, but I'm also ok with keeping everything in one directory. -Mark |
From: Adil <ad...@ya...> - 2006-06-23 18:19:44
|
--- Sean Egan <sea...@gm...> wrote: > Hey guys, > > Now that we're in svn, and new development, > especially that by Adil, > seems to promote it, I think we should probably > restructure our source > tree. How does this look: > > gaim > core > protocols > gtk > console > plugins > > -s > My first attempt was like this: libgaim src protocols plugins gtkgaim src plugins I have the stuff, and some notes here: http://www.site.uottawa.ca/~schow031/gaim/core-ui.html __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Luke S. <lsc...@us...> - 2006-06-23 18:30:05
|
On Fri, Jun 23, 2006 at 11:01:12AM -0700, Sean Egan wrote: > Hey guys, > > Now that we're in svn, and new development, especially that by Adil, > seems to promote it, I think we should probably restructure our source > tree. How does this look: > > gaim > core > protocols > gtk > console > plugins > > -s should the plugins we distribute be split between core and UI? that'd give us gaim core protocols plugins gtk plugins console plugins which may seem like duplication, but would help 1)us to make sure the core/ui split works for plugins 2)authors looking for examples to find pertinent ones 3)similar plugins for the gtk and console UIs to be included luke > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ps: an ad in your email‽ since when does gmail do that? |
From: Richard L. <rl...@wi...> - 2006-06-23 18:55:39
|
On Fri, 2006-06-23 at 14:30 -0400, Luke Schierer wrote: > gaim > core > protocols > plugins > gtk > plugins > console > plugins I agree that we should split plugins like this. That gives us flexibility if we want to distribute parts separately in the future. Richard |
From: Ethan B. <ebl...@cs...> - 2006-06-25 02:27:29
|
Richard Laager spake unto us the following wisdom: > On Fri, 2006-06-23 at 14:30 -0400, Luke Schierer wrote: > > gaim > > core > > protocols > > plugins > > gtk > > plugins > > console > > plugins >=20 > I agree that we should split plugins like this. That gives us > flexibility if we want to distribute parts separately in the future. The disadvantage I see here is replicating the plugin building logic in N places, as well as raising the complexity of building a third-party plugin in-tree (e.g., making sure a Gtk plugin is built in gtk/plugins, not core/plugins). That said, we can probably work it out in some fashion. As far as splitting up the source tarball, I would like to once again register the fact that I am not a fan of this approach. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Gary K. <gr...@re...> - 2006-06-25 04:31:51
|
Ethan Blanton wrote: > Richard Laager spake unto us the following wisdom: >> On Fri, 2006-06-23 at 14:30 -0400, Luke Schierer wrote: >>> gaim >>> core >>> protocols >>> plugins >>> gtk >>> plugins >>> console >>> plugins >> I agree that we should split plugins like this. That gives us >> flexibility if we want to distribute parts separately in the future. > > The disadvantage I see here is replicating the plugin building logic > in N places, as well as raising the complexity of building a > third-party plugin in-tree (e.g., making sure a Gtk plugin is built in > gtk/plugins, not core/plugins). That said, we can probably work it > out in some fashion. Why do we need to handle 3rd party plugin building? I'm under the impression that a simple Makefile that can easily be modified for 3rd party plugins would be a better suited approach. > As far as splitting up the source tarball, I would like to once again > register the fact that I am not a fan of this approach. There are pros and cons to spliting the tarball, but for right now, I think it's fine without splitting it. > Ethan -- Gary Kramlich <gr...@re...> |
From: Ethan B. <ebl...@cs...> - 2006-06-25 14:27:58
|
Gary Kramlich spake unto us the following wisdom: > Why do we need to handle 3rd party plugin building? I'm under the > impression that a simple Makefile that can easily be modified for 3rd > party plugins would be a better suited approach. You mean "a simple[sic] autotools harness". A Makefile would not be sufficient in the general case, unless you mean a Makefile which is generated when you run ./configure on your Gaim build; in that case, we're back to handling 3rd party plugin building. As far as why we should keep it, we should keep it because it looks like *most* people who tinker with Gaim plugins are not sufficiently knowledgeable to get their own out-of-tree autotools etc. fired up. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Gary K. <gr...@re...> - 2006-06-25 16:30:24
|
Ethan Blanton wrote: > Gary Kramlich spake unto us the following wisdom: >> Why do we need to handle 3rd party plugin building? I'm under the >> impression that a simple Makefile that can easily be modified for 3rd >> party plugins would be a better suited approach. > > You mean "a simple[sic] autotools harness". A Makefile would not be > sufficient in the general case, unless you mean a Makefile which is > generated when you run ./configure on your Gaim build; in that case, > we're back to handling 3rd party plugin building. As far as why we > should keep it, we should keep it because it looks like *most* people > who tinker with Gaim plugins are not sufficiently knowledgeable to get > their own out-of-tree autotools etc. fired up. > > Ethan No I meant something like a static Makefile that will build on any unix like environment, as well as cygwin. rlaager has done this for irc-helper [1]. Obviously, this we need to get cleaned up a bit, and we could add different options for different ui's and so on, but this is basically what I was thinking. [1] http://svn.sourceforge.net/viewcvs.cgi/gaim-irchelper/trunk/gaim-irchelper/Makefile?view=markup&rev=143 -- Gary Kramlich <gr...@re...> |
From: Luke S. <lsc...@us...> - 2006-06-23 18:31:50
|
On Fri, Jun 23, 2006 at 02:30:31PM -0400, Luke Schierer wrote: > > ps: an ad in your email‽ since when does gmail do that? > > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 on second look, it appears to be an SF thing, not a gmail thing. The question still more or less stands though. luke |
From: Ethan B. <ebl...@cs...> - 2006-06-25 02:24:56
|
Luke Schierer spake unto us the following wisdom: > On Fri, Jun 23, 2006 at 02:30:31PM -0400, Luke Schierer wrote: > >=20 > > ps: an ad in your email=E2=80=BD since when does gmail do that? > >=20 > > Using Tomcat but need to do more? Need to support web services, securit= y? > > Get stuff done quickly with pre-integrated technology to make your job = easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 >=20 > on second look, it appears to be an SF thing, not a gmail thing. The > question still more or less stands though. And why are they too incompetent to make any sort of effort to mark that it is not part of the original email? I guess that goes right along with just shoving text into a Base64 MIME chunk without even looking... Go sourceforge. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Michael R. H. <bu...@su...> - 2006-06-26 21:04:27
|
On Sat, 2006-06-24 at 22:24 -0400, Ethan Blanton wrote: > And why are they too incompetent to make any sort of effort to mark > that it is not part of the original email? I guess that goes right > along with just shoving text into a Base64 MIME chunk without even > looking... Go sourceforge. If everyone would just sign their messages and use MIME attachments, we'd all find sourceforge's addons as attachments. At least evolution shows the signature strip above the advertisements. > Ethan --=20 Michael R. Head <bu...@su...> suppressingfire.org |
From: Greg H. <ghudson@MIT.EDU> - 2006-06-25 20:04:02
|
On Fri, 2006-06-23 at 11:01 -0700, Sean Egan wrote: > gaim > core > protocols > gtk > console > plugins Directories named "core" can run afoul of tools which expect that name to be used for core files. For instance, if you were to CVS import the gaim source tree after this proposed reorganization, CVS would ignore the "core" directory by default. Ideally, CVS should only ignore files named core, not directories, but it has no mechanism to do so (nor does svn). |
From: Ethan B. <ebl...@cs...> - 2006-06-26 01:34:01
|
Greg Hudson spake unto us the following wisdom: > Directories named "core" can run afoul of tools which expect that name > to be used for core files. For instance, if you were to CVS import the > gaim source tree after this proposed reorganization, CVS would ignore > the "core" directory by default. Ideally, CVS should only ignore files > named core, not directories, but it has no mechanism to do so (nor does > svn). This isn't a big problem ... 'cvs add' or 'svn add' should take care of that, and you only import once. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
From: Gary K. <gr...@re...> - 2006-07-01 20:40:34
|
Greg Hudson wrote: > On Fri, 2006-06-23 at 11:01 -0700, Sean Egan wrote: >> gaim >> core >> protocols >> gtk >> console >> plugins > > Directories named "core" can run afoul of tools which expect that name > to be used for core files. For instance, if you were to CVS import the > gaim source tree after this proposed reorganization, CVS would ignore > the "core" directory by default. Ideally, CVS should only ignore files > named core, not directories, but it has no mechanism to do so (nor does > svn). So, whats the consensus here so that I can start doing this? -- Gary Kramlich <gr...@re...> |
From: Ethan B. <ebl...@cs...> - 2006-07-02 01:00:46
|
Gary Kramlich spake unto us the following wisdom: > Greg Hudson wrote: > > Directories named "core" can run afoul of tools which expect that name > > to be used for core files. For instance, if you were to CVS import the > > gaim source tree after this proposed reorganization, CVS would ignore > > the "core" directory by default. Ideally, CVS should only ignore files > > named core, not directories, but it has no mechanism to do so (nor does > > svn). >=20 > So, whats the consensus here so that I can start doing this? I don't know what *consensus* is, but this is a non-issue. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |