Menu
▾
▴
wxdevide-devs — Developer discussion for the project.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(15) |
Oct
(60) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(19) |
Aug
(8) |
Sep
(21) |
Oct
(16) |
Nov
(8) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(6) |
Apr
(2) |
May
(4) |
Jun
|
Jul
(4) |
Aug
(4) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
(3) |
Feb
(3) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(2) |
|
From: Nuklear Z. <nuk...@gm...> - 2010-07-01 08:15:40
|
its been a lot longer since i last wrote than i expected it would be. i was told i had a 2 week job and it became a 2 and 1 half month job instead. the computer i had to use just couldn't handle mingw and i gave up on things at the time. i am now back at my own computer and have looked at the work i had started before. i have decided to write a notebook from scratch as i couldn't find a good portable way to solve some of the issues i ran into when attaching the DocManager to a notebook. hacking an existing notebook or other hacky workarounds are liable to bite later. so i am building a notebook that will solve both the back end issues i ran into and add some new fun features as well. i am hoping that it will turn into a good stable component that is not a pure nightmare to then write various renderers for, so that any visual style can be accomplished. if it is successful i will release it in wxCode or something. here are a few things that it will do that notebook components do not support: each tab can hold a unique id that does not change when the tab id does storing a window for a tab is optional rather than required (used in conjunction with the unique id) the component can be used in two different modes, either like a regular notebook where tabs switch windows unless the tab does not have a window to handle. or purely a tab control. the notebook may have a single window attached to it. separately from those handled by the tabs (used in conjunction with the unique id, the tab control optionally may use this feature) a few events will probably be needed to handle switching from a window tab to a non window tab and such, and possibly settings also since i will be drawing the notebook anyway it can simultaneously support tabs on any of the 4 borders at the same time i figured since i had to reinvent the wheel i might as well make it a bit better than the rest. the pages will remain separate from the drawing code to keep things clean. once i have this working i'll create a new DocBook class to handle the DocManager using the notebook and then continue working on the editor plugin component. i don't know what if any work/ideas have been put into the form designer. if anyone has lets hear about it. i know Tony was looking at the wxResizableButton, and it fails on gtk, was any solution found or is it still in the air? also has anyone done enough work with the wxXML class to know if it can handle what xml we need or do we quite know yet? Nuklear |
|
From: Tony R. <re...@al...> - 2010-05-06 02:58:07
|
Good guess. I just tried the same code with the gtk version under Ubuntu. It compiles and starts ok, but there seems to be something wrong with the events. I think the CaptureMouse code might be the culprit (the mouse seems to hang after clicking the movable widget). However, it might still be a good route to take. I'll have to play with it more to see where the offending code lays. -Tony On Wed, May 5, 2010 at 6:55 PM, Nuklear Zelph <nuk...@gm...>wrote: > Tony does that class work as expected under the gtk port? i wrote some > dragwindow code on msw and tried it in linux and it failed miserably. i > don't know why it would not drag, but it didn't. its been some time since i > messed with it and i have not done much in the way of figuring out why. that > could be an issue, but not knowing the root problem i can't say. i'm pretty > sure gtk2 handles dragging fine so i must have missed something. anyway that > is one platform issue we need to watch out for. and we should keep an eye on > that kind of thing as we go along so we don't pay for a big oversight later > on. > > my document manager notebook is not going so well. it worked i stopped > working on it for a little while and had to go out of state for some work. > i'm using some one elses box and i cant add 2 tabs to the notebook or the > program crashes. i tried porting to wxFlatNotebook same result. its demo app > is doing the same thing. plus i get an exception right off when running the > debugger that lands me in the stl string header. so i am going to disect > this and find out why. i also built wx-2.8.11 but i have a linker error in > wxScintilla now. its all a big mess. > > Nuklear > > > On Wed, May 5, 2010 at 6:16 PM, Tony Reina <re...@al...> wrote: > >> I think I figured out the solution to wxWidgets components that are >> movable and resizable at runtime. The new class (Movable) has been templated >> so that a call to "Movable<wxButton>" will create a new wxButton that moves >> at runtime. I've attached the project to demonstrate. >> >> This could make a good foundation for the new RAD. >> >> -Tony >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Wxdevide-devs mailing list >> Wxd...@li... >> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Nuklear Z. <nuk...@gm...> - 2010-05-06 01:55:25
|
Tony does that class work as expected under the gtk port? i wrote some dragwindow code on msw and tried it in linux and it failed miserably. i don't know why it would not drag, but it didn't. its been some time since i messed with it and i have not done much in the way of figuring out why. that could be an issue, but not knowing the root problem i can't say. i'm pretty sure gtk2 handles dragging fine so i must have missed something. anyway that is one platform issue we need to watch out for. and we should keep an eye on that kind of thing as we go along so we don't pay for a big oversight later on. my document manager notebook is not going so well. it worked i stopped working on it for a little while and had to go out of state for some work. i'm using some one elses box and i cant add 2 tabs to the notebook or the program crashes. i tried porting to wxFlatNotebook same result. its demo app is doing the same thing. plus i get an exception right off when running the debugger that lands me in the stl string header. so i am going to disect this and find out why. i also built wx-2.8.11 but i have a linker error in wxScintilla now. its all a big mess. Nuklear On Wed, May 5, 2010 at 6:16 PM, Tony Reina <re...@al...> wrote: > I think I figured out the solution to wxWidgets components that are movable > and resizable at runtime. The new class (Movable) has been templated so that > a call to "Movable<wxButton>" will create a new wxButton that moves at > runtime. I've attached the project to demonstrate. > > This could make a good foundation for the new RAD. > > -Tony > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Esteban A. B. <nab...@ya...> - 2010-04-01 18:29:07
|
That editor look suspiciously similar to Notepad++. --- El mié, 3/31/10, Tony Reina <re...@al...> escribió: De: Tony Reina <re...@al...> Asunto: Re: [Wxdevide-devs] doc manager and notebook A: "Nuklear Zelph" <nuk...@gm...> Cc: wxd...@li..., "Sof.T" <so...@ti...>, "Esteban" <nab...@ya...>, "Malcolm Nealon" <mal...@gm...> Fecha: miércoles, 31 de marzo de 2010, 12:00 pm That sounds like good progress. I'm definitely interested in getting off of bug fixing for wxDev-C++. One editor that I really like is: http://www.e-texteditor.com/ Look at the screencast for the examples of snippets and search/replace. My jaw dropped. It would be nice if we could use that as a template for goal features. I think once you are satisfied with the generic IDE part, our goal should be to work together for the RAD plugin. Again, that's the most important feature once the generic IDE has been framed. The size_t thing is odd. I was under the impression that size_t was a positive (or 0) integer. So -1 should be a no-no. According the the spec, I think it would be interpreted as a binary 11. -Tony On Tue, Mar 30, 2010 at 4:57 PM, Nuklear Zelph <nuk...@gm...> wrote: i have not quite finished both of these classes, the doc manager and the doc book. i am hacking the notebook class, it's from Eran's codelite V1. the events where not triggering where they needed to (notebooks parent) and i also added the option of a spin button. there are a few bugs i'd like to fix too, but it works pretty well. i like how it looks and the bigger advantage is that it supports placing buttons on all 4 of the borders not just the top one like wxFlatNotebook. (unless he's fixed that since i looked at it last.) the docmanager works bug free i believe in document changing, but i still want to implement the extra information storage. like color theme in use, text selection and whatever else Scintilla does not keep. i don't know if it keeps folding or not, but i will take care of that too if it does not. i believe it keeps bookmarks though. docbook is a notebook implementation that uses the docmanager and still allows addition of your own windows to the tabs. the only error i know of on that front atm is that it will not delete the window you add. (since it never deletes xstc) i am going to fix those issues in the notebook class later but i figured i should give out what i have. i still have some sorting out to do for the text editor codebase since i have 3-4 variations of sources i started in the past all piled up. once i have that done ill post it to my website so its easier to get a hold of. let me know what you think of this. it should act on the outside like any other notebook where there is one window per page and u can access each individually. obviously allowing the notebook to take care of deleting its children. if there is a feature you think is missing let me know. i'm using this in my notebook, but if we want to use a different notebook class like the default one in wxWidgets i can put that together. i know that we don't want to store any external code we don't need to and this hacked notebook would count as one. i have not gotten to the rest of the editor plugin yet. i need to take a look at the plugin design again for a refresher. i did start a templated editor dialog, but i have not looked at it in a while. one thing that confuses me in the notebook is that it uses size_t (unsigned int) but its invalid id is designated as static size_t -1. am i missing something? Nuklear ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Wxdevide-devs mailing list Wxd...@li... https://lists.sourceforge.net/lists/listinfo/wxdevide-devs ____________________________________________________________________________________ ¡Obtén la mejor experiencia en la web! Descarga gratis el nuevo Internet Explorer 8. http://downloads.yahoo.com/ieak8/?l=e1 |
|
From: Nuklear Z. <nuk...@gm...> - 2010-04-01 02:30:32
|
On Wed, Mar 31, 2010 at 8:29 PM, Nuklear Zelph <nuk...@gm...>wrote: > lets brainstorm what we are trying to do and all the little bits involved. > all the featues it will have and how the thing is going to look. while we > are doing that lets get some dependent resources built like the project > space manager (parse project files and the tree ctrl and stuff) settings > manager, what else is there? project templates, docking support that should > be as easy as aui. > > once we have those figured out and built we should have a good collection > of what we need to do written down. doing it this way will also give us time > to get the other things we are working on out of the way like finishing > folding dev and debugging/finishing the docbook/manager classes and such. > once we are there we will have had some time to think about it and we wont > have a lot of distractions to deal with at the same time. that is probably a > good way to approach the plugin system too. > > does that sound ok? here is the page i just put up on trac: > https://sourceforge.net/apps/trac/wxdevide/wiki/FormDesigner > > > Nuklear > > > On Wed, Mar 31, 2010 at 5:17 PM, Tony Reina <re...@al...> wrote: > >> Ok. I like that idea, but am not sure where to start in the implementation >> of the form designer in C++/wxWidgets. >> >> -Tony >> >> >> On Wed, Mar 31, 2010 at 3:22 PM, Nuklear Zelph <nuk...@gm...>wrote: >> >>> no what i meant was that we keep the delphi ide for now and focus on the >>> form designer in c++. between the two in the end, the form designer has more >>> end user value since it will be a true WYSIWYG. the ide can have some other >>> features and some that work better but it is pretty good right now and will >>> not have AS dramatic results. (especially for a longer period of time) so we >>> put off the plugin framework for the time being and the c++ ide and write >>> the c++ form designer to be useable with the plugin system in the future. >>> hence the api layer. >>> >>> Nuklear >>> >>> >>> On Wed, Mar 31, 2010 at 3:17 PM, Tony Reina <re...@al...> wrote: >>> >>>> >>>> the basic idea for the interfacing code for the form designer >>>>> (connecting it to the gui) is basically like what scintilla does. the form >>>>> designer is its own module, it can have a modular structure too. then the >>>>> parts that need either user input, config read/write and whatever else are >>>>> routed to an interfacing api. then we use that api with a standalone >>>>> executable directly (the gui uses it natively) as long as we do it right we >>>>> only need to build a wrapper api for that to connect the form designer into >>>>> the plugin system for wxDevIDE. that also allows the form designer to be >>>>> used in other projects too like if Code::Blocks users wanted to use it. >>>>> hopefully y'all understood what i'm trying to say. that should kinda kill >>>>> several birds with one stone. >>>>> >>>>> >>>> So are you saying that we keep the Delphi plugin of the form designer >>>> (for now) and just allow it to hook into wxDevIDE? I was hoping that we >>>> would at least eventually migrate the form designer to wxWidgets/C++ so that >>>> it is a true WYSIWYG cross-platform version. >>>> >>>> -Tony >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Wxdevide-devs mailing list >>> Wxd...@li... >>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>> >>> >> > |
|
From: Tony R. <re...@al...> - 2010-03-31 23:17:29
|
Ok. I like that idea, but am not sure where to start in the implementation of the form designer in C++/wxWidgets. -Tony On Wed, Mar 31, 2010 at 3:22 PM, Nuklear Zelph <nuk...@gm...>wrote: > no what i meant was that we keep the delphi ide for now and focus on the > form designer in c++. between the two in the end, the form designer has more > end user value since it will be a true WYSIWYG. the ide can have some other > features and some that work better but it is pretty good right now and will > not have AS dramatic results. (especially for a longer period of time) so we > put off the plugin framework for the time being and the c++ ide and write > the c++ form designer to be useable with the plugin system in the future. > hence the api layer. > > Nuklear > > > On Wed, Mar 31, 2010 at 3:17 PM, Tony Reina <re...@al...> wrote: > >> >> the basic idea for the interfacing code for the form designer (connecting >>> it to the gui) is basically like what scintilla does. the form designer is >>> its own module, it can have a modular structure too. then the parts that >>> need either user input, config read/write and whatever else are routed to an >>> interfacing api. then we use that api with a standalone executable directly >>> (the gui uses it natively) as long as we do it right we only need to build a >>> wrapper api for that to connect the form designer into the plugin system for >>> wxDevIDE. that also allows the form designer to be used in other projects >>> too like if Code::Blocks users wanted to use it. hopefully y'all understood >>> what i'm trying to say. that should kinda kill several birds with one stone. >>> >>> >>> >> So are you saying that we keep the Delphi plugin of the form designer (for >> now) and just allow it to hook into wxDevIDE? I was hoping that we would at >> least eventually migrate the form designer to wxWidgets/C++ so that it is a >> true WYSIWYG cross-platform version. >> >> -Tony >> >> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Nuklear Z. <nuk...@gm...> - 2010-03-31 22:22:33
|
no what i meant was that we keep the delphi ide for now and focus on the form designer in c++. between the two in the end, the form designer has more end user value since it will be a true WYSIWYG. the ide can have some other features and some that work better but it is pretty good right now and will not have AS dramatic results. (especially for a longer period of time) so we put off the plugin framework for the time being and the c++ ide and write the c++ form designer to be useable with the plugin system in the future. hence the api layer. Nuklear On Wed, Mar 31, 2010 at 3:17 PM, Tony Reina <re...@al...> wrote: > > the basic idea for the interfacing code for the form designer (connecting >> it to the gui) is basically like what scintilla does. the form designer is >> its own module, it can have a modular structure too. then the parts that >> need either user input, config read/write and whatever else are routed to an >> interfacing api. then we use that api with a standalone executable directly >> (the gui uses it natively) as long as we do it right we only need to build a >> wrapper api for that to connect the form designer into the plugin system for >> wxDevIDE. that also allows the form designer to be used in other projects >> too like if Code::Blocks users wanted to use it. hopefully y'all understood >> what i'm trying to say. that should kinda kill several birds with one stone. >> >> >> > So are you saying that we keep the Delphi plugin of the form designer (for > now) and just allow it to hook into wxDevIDE? I was hoping that we would at > least eventually migrate the form designer to wxWidgets/C++ so that it is a > true WYSIWYG cross-platform version. > > -Tony > > |
|
From: Tony R. <re...@al...> - 2010-03-31 21:17:49
|
> the basic idea for the interfacing code for the form designer (connecting > it to the gui) is basically like what scintilla does. the form designer is > its own module, it can have a modular structure too. then the parts that > need either user input, config read/write and whatever else are routed to an > interfacing api. then we use that api with a standalone executable directly > (the gui uses it natively) as long as we do it right we only need to build a > wrapper api for that to connect the form designer into the plugin system for > wxDevIDE. that also allows the form designer to be used in other projects > too like if Code::Blocks users wanted to use it. hopefully y'all understood > what i'm trying to say. that should kinda kill several birds with one stone. > > > So are you saying that we keep the Delphi plugin of the form designer (for now) and just allow it to hook into wxDevIDE? I was hoping that we would at least eventually migrate the form designer to wxWidgets/C++ so that it is a true WYSIWYG cross-platform version. -Tony |
|
From: Nuklear Z. <nuk...@gm...> - 2010-03-31 20:26:36
|
On Wed, Mar 31, 2010 at 2:25 PM, Nuklear Zelph <nuk...@gm...>wrote: > i have looked at the screencast before, when Scintilla 2.01 came out it > said that it now supports multiple selection. i figured that was kinda the > same thing or a base that could be worked from to achieve it. i tried to > figure it out briefly but had other things to do and didn't go back. i > imagine it would take a graphical update to the platform code in > wxScintilla/STC to make it look right. maybe even to use it because of > events, but i just don't know yet. > > the bundles look like just plugin scripts which isn't probably all that > tough to support. actually writing the scripts is another matter obviously. > i'm hoping to support something like that in my text editor some day, but i > don't know what route i will take and it wont happen till the rest of it is > finished, who knows when that might finally be. > > if we remove the current editor from the ide codebase we have currently and > replace it with the scintilla one i have put together and make it at least a > useable text editor. add some settings for the editor too that do work, it > will be some kind of progress to users. i think that is about all we can > hope for right now before we build a plugin system. however the form > designer is a seperate project in itself, it just needs to fit into the > ide's plugin system down the road. since we already have a fully functional > working ide anyway, (delphi version) i think we can get away with putting > off the ide for now and the plugin system. also i believe as long as we keep > the thing modular like we talked about we can make two versions of > interfacing code to solve the now and later usability. > > the basic idea for the interfacing code for the form designer (connecting > it to the gui) is basically like what scintilla does. the form designer is > its own module, it can have a modular structure too. then the parts that > need either user input, config read/write and whatever else are routed to an > interfacing api. then we use that api with a standalone executable directly > (the gui uses it natively) as long as we do it right we only need to build a > wrapper api for that to connect the form designer into the plugin system for > wxDevIDE. that also allows the form designer to be used in other projects > too like if Code::Blocks users wanted to use it. hopefully y'all understood > what i'm trying to say. that should kinda kill several birds with one stone. > > > Is there any reason that plan will not work or does it need some revisions? > > Nuklear > > > > > > > On Wed, Mar 31, 2010 at 12:00 PM, Tony Reina <re...@al...> wrote: > >> That sounds like good progress. I'm definitely interested in getting off >> of bug fixing for wxDev-C++. >> >> One editor that I really like is: http://www.e-texteditor.com/ Look at >> the screencast for the examples of snippets and search/replace. My jaw >> dropped. It would be nice if we could use that as a template for goal >> features. >> >> I think once you are satisfied with the generic IDE part, our goal should >> be to work together for the RAD plugin. Again, that's the most important >> feature once the generic IDE has been framed. >> >> The size_t thing is odd. I was under the impression that size_t was a >> positive (or 0) integer. So -1 should be a no-no. According the the spec, I >> think it would be interpreted as a binary 11. >> >> -Tony >> >> >> >> >> On Tue, Mar 30, 2010 at 4:57 PM, Nuklear Zelph <nuk...@gm...>wrote: >> >>> i have not quite finished both of these classes, the doc manager and the >>> doc book. i am hacking the notebook class, it's from Eran's codelite V1. the >>> events where not triggering where they needed to (notebooks parent) and i >>> also added the option of a spin button. there are a few bugs i'd like to fix >>> too, but it works pretty well. i like how it looks and the bigger advantage >>> is that it supports placing buttons on all 4 of the borders not just the top >>> one like wxFlatNotebook. (unless he's fixed that since i looked at it last.) >>> >>> the docmanager works bug free i believe in document changing, but i still >>> want to implement the extra information storage. like color theme in use, >>> text selection and whatever else Scintilla does not keep. i don't know if it >>> keeps folding or not, but i will take care of that too if it does not. i >>> believe it keeps bookmarks though. >>> >>> docbook is a notebook implementation that uses the docmanager and still >>> allows addition of your own windows to the tabs. the only error i know of on >>> that front atm is that it will not delete the window you add. (since it >>> never deletes xstc) i am going to fix those issues in the notebook class >>> later but i figured i should give out what i have. i still have some sorting >>> out to do for the text editor codebase since i have 3-4 variations of >>> sources i started in the past all piled up. once i have that done ill post >>> it to my website so its easier to get a hold of. >>> >>> let me know what you think of this. it should act on the outside like any >>> other notebook where there is one window per page and u can access each >>> individually. obviously allowing the notebook to take care of deleting its >>> children. if there is a feature you think is missing let me know. i'm using >>> this in my notebook, but if we want to use a different notebook class like >>> the default one in wxWidgets i can put that together. i know that we don't >>> want to store any external code we don't need to and this hacked notebook >>> would count as one. >>> >>> i have not gotten to the rest of the editor plugin yet. i need to take a >>> look at the plugin design again for a refresher. i did start a templated >>> editor dialog, but i have not looked at it in a while. >>> >>> one thing that confuses me in the notebook is that it uses size_t >>> (unsigned int) but its invalid id is designated as static size_t -1. am i >>> missing something? >>> >>> Nuklear >>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Wxdevide-devs mailing list >>> Wxd...@li... >>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>> >>> >> > |
|
From: Tony R. <re...@al...> - 2010-03-31 18:07:53
|
That sounds like good progress. I'm definitely interested in getting off of bug fixing for wxDev-C++. One editor that I really like is: http://www.e-texteditor.com/ Look at the screencast for the examples of snippets and search/replace. My jaw dropped. It would be nice if we could use that as a template for goal features. I think once you are satisfied with the generic IDE part, our goal should be to work together for the RAD plugin. Again, that's the most important feature once the generic IDE has been framed. The size_t thing is odd. I was under the impression that size_t was a positive (or 0) integer. So -1 should be a no-no. According the the spec, I think it would be interpreted as a binary 11. -Tony On Tue, Mar 30, 2010 at 4:57 PM, Nuklear Zelph <nuk...@gm...>wrote: > i have not quite finished both of these classes, the doc manager and the > doc book. i am hacking the notebook class, it's from Eran's codelite V1. the > events where not triggering where they needed to (notebooks parent) and i > also added the option of a spin button. there are a few bugs i'd like to fix > too, but it works pretty well. i like how it looks and the bigger advantage > is that it supports placing buttons on all 4 of the borders not just the top > one like wxFlatNotebook. (unless he's fixed that since i looked at it last.) > > the docmanager works bug free i believe in document changing, but i still > want to implement the extra information storage. like color theme in use, > text selection and whatever else Scintilla does not keep. i don't know if it > keeps folding or not, but i will take care of that too if it does not. i > believe it keeps bookmarks though. > > docbook is a notebook implementation that uses the docmanager and still > allows addition of your own windows to the tabs. the only error i know of on > that front atm is that it will not delete the window you add. (since it > never deletes xstc) i am going to fix those issues in the notebook class > later but i figured i should give out what i have. i still have some sorting > out to do for the text editor codebase since i have 3-4 variations of > sources i started in the past all piled up. once i have that done ill post > it to my website so its easier to get a hold of. > > let me know what you think of this. it should act on the outside like any > other notebook where there is one window per page and u can access each > individually. obviously allowing the notebook to take care of deleting its > children. if there is a feature you think is missing let me know. i'm using > this in my notebook, but if we want to use a different notebook class like > the default one in wxWidgets i can put that together. i know that we don't > want to store any external code we don't need to and this hacked notebook > would count as one. > > i have not gotten to the rest of the editor plugin yet. i need to take a > look at the plugin design again for a refresher. i did start a templated > editor dialog, but i have not looked at it in a while. > > one thing that confuses me in the notebook is that it uses size_t (unsigned > int) but its invalid id is designated as static size_t -1. am i missing > something? > > Nuklear > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Nuklear Z. <nuk...@gm...> - 2010-03-30 23:57:21
|
i have not quite finished both of these classes, the doc manager and the doc book. i am hacking the notebook class, it's from Eran's codelite V1. the events where not triggering where they needed to (notebooks parent) and i also added the option of a spin button. there are a few bugs i'd like to fix too, but it works pretty well. i like how it looks and the bigger advantage is that it supports placing buttons on all 4 of the borders not just the top one like wxFlatNotebook. (unless he's fixed that since i looked at it last.) the docmanager works bug free i believe in document changing, but i still want to implement the extra information storage. like color theme in use, text selection and whatever else Scintilla does not keep. i don't know if it keeps folding or not, but i will take care of that too if it does not. i believe it keeps bookmarks though. docbook is a notebook implementation that uses the docmanager and still allows addition of your own windows to the tabs. the only error i know of on that front atm is that it will not delete the window you add. (since it never deletes xstc) i am going to fix those issues in the notebook class later but i figured i should give out what i have. i still have some sorting out to do for the text editor codebase since i have 3-4 variations of sources i started in the past all piled up. once i have that done ill post it to my website so its easier to get a hold of. let me know what you think of this. it should act on the outside like any other notebook where there is one window per page and u can access each individually. obviously allowing the notebook to take care of deleting its children. if there is a feature you think is missing let me know. i'm using this in my notebook, but if we want to use a different notebook class like the default one in wxWidgets i can put that together. i know that we don't want to store any external code we don't need to and this hacked notebook would count as one. i have not gotten to the rest of the editor plugin yet. i need to take a look at the plugin design again for a refresher. i did start a templated editor dialog, but i have not looked at it in a while. one thing that confuses me in the notebook is that it uses size_t (unsigned int) but its invalid id is designated as static size_t -1. am i missing something? Nuklear |
|
From: M N. <m.n...@wa...> - 2009-11-29 07:44:29
|
Nice to see it added, we just need the dll build of your libraries too. Regards Mal On Sat, Nov 28, 2009 at 2:29 PM, Tony Reina <re...@al...> wrote: > I was thinking it should go on our wxDev-C++ webupdate page. If you send me > the devpak, I can add it. > > -Tony > > > > On Fri, Nov 27, 2009 at 8:18 PM, Nuklear Zelph <nuk...@gm...>wrote: > >> ok, i'll take care of it. what folder should i put it in the webspace? >> >> Nuklear >> >> >> On Fri, Nov 27, 2009 at 2:19 PM, Tony Reina <tb...@gm...> wrote: >> >>> Yes, it would help if we had devpaks for whatever 3rd party stuff was >>> used. This way we are all using the same development platform. >>> >>> -Tony >>> >>> >>> On Fri, Nov 27, 2009 at 12:51 PM, M Nealon <m.n...@wa...> wrote: >>> >>>> Hi all, especially Nuklear, >>>> >>>> Would it be an idea to create a devpak of your xstc component? If you >>>> generate and maintain this, then we won't need to go to the trouble of doing >>>> it ourselves. >>>> >>>> It would make sense when we are attempting to appraise your demo app >>>> (for example). >>>> >>>> Best regards >>>> Mal >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>>> 30-Day >>>> trial. Simplify your report design, integration and deployment - and >>>> focus on >>>> what you do best, core application coding. Discover what's new with >>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>>> _______________________________________________ >>>> Wxdevide-devs mailing list >>>> Wxd...@li... >>>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Wxdevide-devs mailing list >>> Wxd...@li... >>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Wxdevide-devs mailing list >> Wxd...@li... >> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Tony R. <re...@al...> - 2009-11-28 13:29:20
|
I was thinking it should go on our wxDev-C++ webupdate page. If you send me the devpak, I can add it. -Tony On Fri, Nov 27, 2009 at 8:18 PM, Nuklear Zelph <nuk...@gm...>wrote: > ok, i'll take care of it. what folder should i put it in the webspace? > > Nuklear > > > On Fri, Nov 27, 2009 at 2:19 PM, Tony Reina <tb...@gm...> wrote: > >> Yes, it would help if we had devpaks for whatever 3rd party stuff was >> used. This way we are all using the same development platform. >> >> -Tony >> >> >> On Fri, Nov 27, 2009 at 12:51 PM, M Nealon <m.n...@wa...> wrote: >> >>> Hi all, especially Nuklear, >>> >>> Would it be an idea to create a devpak of your xstc component? If you >>> generate and maintain this, then we won't need to go to the trouble of doing >>> it ourselves. >>> >>> It would make sense when we are attempting to appraise your demo app (for >>> example). >>> >>> Best regards >>> Mal >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >>> 30-Day >>> trial. Simplify your report design, integration and deployment - and >>> focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july >>> _______________________________________________ >>> Wxdevide-devs mailing list >>> Wxd...@li... >>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Wxdevide-devs mailing list >> Wxd...@li... >> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Nuklear Z. <nuk...@gm...> - 2009-11-28 04:18:59
|
ok, i'll take care of it. what folder should i put it in the webspace? Nuklear On Fri, Nov 27, 2009 at 2:19 PM, Tony Reina <tb...@gm...> wrote: > Yes, it would help if we had devpaks for whatever 3rd party stuff was used. > This way we are all using the same development platform. > > -Tony > > > On Fri, Nov 27, 2009 at 12:51 PM, M Nealon <m.n...@wa...> wrote: > >> Hi all, especially Nuklear, >> >> Would it be an idea to create a devpak of your xstc component? If you >> generate and maintain this, then we won't need to go to the trouble of doing >> it ourselves. >> >> It would make sense when we are attempting to appraise your demo app (for >> example). >> >> Best regards >> Mal >> >> >> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and focus >> on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Wxdevide-devs mailing list >> Wxd...@li... >> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >> >> > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Tony R. <tb...@gm...> - 2009-11-27 22:19:20
|
Yes, it would help if we had devpaks for whatever 3rd party stuff was used. This way we are all using the same development platform. -Tony On Fri, Nov 27, 2009 at 12:51 PM, M Nealon <m.n...@wa...> wrote: > Hi all, especially Nuklear, > > Would it be an idea to create a devpak of your xstc component? If you > generate and maintain this, then we won't need to go to the trouble of doing > it ourselves. > > It would make sense when we are attempting to appraise your demo app (for > example). > > Best regards > Mal > > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: M N. <m.n...@wa...> - 2009-11-27 20:51:22
|
Hi all, especially Nuklear, Would it be an idea to create a devpak of your xstc component? If you generate and maintain this, then we won't need to go to the trouble of doing it ourselves. It would make sense when we are attempting to appraise your demo app (for example). Best regards Mal |
|
From: Nuklear Z. <nuk...@gm...> - 2009-11-24 00:54:08
|
those are on my website: nuklearzelph.org. look at the wxDevIDE page under Software Projects. i did some other work to the text style code last night too. i will post a snapshot on my website and keep it up-to-date till we decide how to organize the source tree. Nuklear On Mon, Nov 23, 2009 at 1:36 PM, Tony Reina <tb...@gm...> wrote: > I'm getting errors about the ColorButton files not being there. > > -Tony > > > > On Sun, Nov 22, 2009 at 11:15 AM, Nuklear Zelph <nuk...@gm...>wrote: > >> this is the code i have so far. i got kinda burned out on the dialog >> solution so i have shrunk away from the project for a couple weeks. i did >> start the textStyle container and a simple parser for it this week. i don't >> expect the parser to be very powerful if i get it to work, just mostly for a >> simple xml to disk storage format for the styled text. it might not be very >> easy to parse with xslt, but that is why i have an xml to text container >> class too. it may not be the most useful in practice, but it should be light >> enough not to matter much. >> >> i was thinking about making the notebook api compatible with the >> wxNotebook class for simplicity, but still use the other functions like in >> wxFlatNotebook and Notebook. i think it will probably just be a >> compatibility layer, or virtual so that either approach could be the main, >> depending on the real class used. >> >> there is a lot of stuff to deal with, i have kinda been doing ring around >> the rosey with all the bits, but so far my brain has not melted down. the >> code is organized per each api, but everything is probably not laid out real >> clear, i just made a snapshot of what i have done. so far i think everything >> will work fine except for maybe the dialog solution since it does not seem >> to be "aware" of the users version in the dialogdata class. i gave up on it >> for now so i could work on the text style container and maybe i can figure >> out what i am forgetting later. >> >> Nuklear >> > > |
|
From: Tony R. <tb...@gm...> - 2009-11-23 21:36:47
|
I'm getting errors about the ColorButton files not being there. -Tony On Sun, Nov 22, 2009 at 11:15 AM, Nuklear Zelph <nuk...@gm...>wrote: > this is the code i have so far. i got kinda burned out on the dialog > solution so i have shrunk away from the project for a couple weeks. i did > start the textStyle container and a simple parser for it this week. i don't > expect the parser to be very powerful if i get it to work, just mostly for a > simple xml to disk storage format for the styled text. it might not be very > easy to parse with xslt, but that is why i have an xml to text container > class too. it may not be the most useful in practice, but it should be light > enough not to matter much. > > i was thinking about making the notebook api compatible with the wxNotebook > class for simplicity, but still use the other functions like in > wxFlatNotebook and Notebook. i think it will probably just be a > compatibility layer, or virtual so that either approach could be the main, > depending on the real class used. > > there is a lot of stuff to deal with, i have kinda been doing ring around > the rosey with all the bits, but so far my brain has not melted down. the > code is organized per each api, but everything is probably not laid out real > clear, i just made a snapshot of what i have done. so far i think everything > will work fine except for maybe the dialog solution since it does not seem > to be "aware" of the users version in the dialogdata class. i gave up on it > for now so i could work on the text style container and maybe i can figure > out what i am forgetting later. > > Nuklear > |
|
From: Esteban A. B. <nab...@ya...> - 2009-10-26 14:38:39
|
Fair enough. We now return to our regularly scheduled programming... --- El lun 26-oct-09, Nuklear Zelph <nuk...@gm...> escribió: > De: Nuklear Zelph <nuk...@gm...> > Asunto: Re: [Wxdevide-devs] Maybe stupid suggestion, but someone has to make it > A: wxd...@li... > Fecha: lunes, 26 octubre, 2009, 1:46 am > i can't say i like the idea, i have > used C::B enough to know that it works quite a bit > differently and that only makes it all the more tempting to > create devblocks not Dev-C++ in C++. i am working away from > windows as a primary os because of what has happened in xp > sp2 and vista. i need an ide i like to be fully comfortable, > but c::b works for now. i also need a text editor, but i am > already building it. i would use fedora a lot more, but > every time i call up gnome edit i get pissed and remember > just how much i need a better editor. its like MS super > notebook, not like what i need. wine is good to a point, but > i have run into issues with it in the past too. > > > so, if looking at codeblocks plugin system will help speed > things up, ok, but lets write out own code. i don't like > the idea that they own part of our work. libraries are a > different story, but... if we make a complete gui that is > basically a working text editor while > we work on the plugin system/manager then the program will > be usefull > even before its functional. it will give us time to create > the plugin > system to allow for the compiler and debugger and stuff > too. we can > speed that part when it comes by wrapping c::b plugins to > work with > wxDevIDE. then we can write out own makefile based compiler > plugins and > the ide will be useful sooner than it would have been.that > is another idea. > > i figued out some of the completion problems i was having, > i think i can make a workable api, but it is not finished > like scintilla meant it to be i don't think. if we need > more developers, lets get on sf and see if anyone is > interested. we can put up a help wanted so people know. > maybe the wxforum can help, any other ideas? we are the > primary developers, we know the insides the best between us > all, but we can only do so much in a given amount of time > per each of us. will that make you feel better? > > > oh, stc did add some functionality too, i merged it into my > wxScintilla, but now that they are working on it, i think > that stc is the right way to go for the official scintilla > editor backend, using xstc of course. they changed the > library name to wxscintilla, so that was a bit confusing at > first, that is why i thought they had both in the source > tree at first, probably why i was told that by someone too. > offical wxScitilla is dead and might as well be ignored. i > am keeping mine updated, because when i am done building my > text editor i am going to hack wxScintila to optionally let > the user set an image background and i can't have a > textctrl base in the way. > > > Nuklear > > On Sun, Oct 25, 2009 at 7:47 PM, > Tony Reina <tb...@gm...> > wrote: > > It's certainly not a bad suggestion. Plus, it is a > question that we will probably get from many, many other > people. > > Although I'm not opposed to the idea of just modifying > Code::Blocks, my purpose behind this project is to build an > IDE from scratch just to get the experience and satisfaction > of doing so. To me, this is more about the journey than the > destination. > > > > I have no idea how long this project will take and > haven't even given consideration to timelines at this > point (other than the timeline of when we start). That's > the reason I wanted to get version 7 of wxDev-C++ finished > before we started this. If it takes several years and we > still don't have anything useful, then at least we have > wxDev-C++ out there. > > > > -Tony > > > On Sun, Oct 25, 2009 at 5:52 PM, > Esteban Aguilar B. <nab...@ya...> > wrote: > > > Hi, in advance, please forgive me if someone has already > suggested this (maybe even I could have dismissed a similar > suggestion, I just don't recall right now :D ). > > > > I don't want to introduce controversy at this point but > I think this needs to be at least considered and discussed > as an option. > > > > I have always had my concerns in regards to the > effectiveness of starting an IDE again from 0, mostly > because I've seen time and time again, open source > projects get abandoned before actually being useful or close > to "version 1.0" form. I don't want to be > negative, but from all signs, at least as of now, we > don't look to have enough man power to get this project > to a useful state in an acceptable time frame.. (like less > than 2 or 3 years). When I say "acceptable", > I'm thinking, before our lives have a chance of changing > enough that most of us are no longer able to keep working on > this, while having at least a mature enough product that may > attract some other devels to continue the work at that > point, if such thing happens. > > > > > > Anyway, I know that having full control of the code from > day zero would be great, but I'm thinking.... how about > we grab Code::Blocks code, and try to morph its GUI to look > and act just like we want wxDevIDE to be (alas, like > wxDevCpp)? > > > > > > This software appears to have such strong foundation; it is > popular, it has already plugin infrastructure built in, it > has even many plugins already, and support for several > compilers. I think it would be a little silly to replicate > that work, if we care mostly for how it works for the end > user... > > > > > > Someone could say that we could end up in a similar > position as we were with wxDevCpp, in that we may en up > depending from "others" work, but I think that the > difference here is that we are now in wxWidgets/C++ camp, so > we no longer have the delphi limitations for doing whatever > changes we feel we need to do. For example, if they > don't use wxScintilla or whatever for the editor, we can > develop our one component. > > > > > > I think this approach has many benefits: First, MUCH faster > and realistic time to come up with a 1.0 version. If this > version actually sees the light of day, that means that our > work would not be in vane. Second, better reuse of open > source code. Also, our plugins, or other improvements could > theoretically be retro-added to C::B, giving them some > benefits. Fourth, we have potentially more developers able > to develop plugins. I think there are more, but I don't > want to extend this message much more. > > > > > > If this was already suggested, I would like to read again > why we didn't like this option :) > > > > > > > > > ____________________________________________________________________________________ > > ¡Obtén la mejor experiencia en la web! > > Descarga gratis el nuevo Internet Explorer 8. > > http://downloads.yahoo.com/ieak8/?l=e1 > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference > in SF, CA > > is the only developer event you need to attend this year. > Jumpstart your > > developing skills, take BlackBerry mobile applications to > market and stay > > ahead of the curve. Join us from November 9 - 12, 2009. > Register now! > > http://p.sf.net/sfu/devconference > > _______________________________________________ > > Wxdevide-devs mailing list > > Wxd...@li... > > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > > > > ------------------------------------------------------------------------------ > > Come build with us! The BlackBerry(R) Developer Conference > in SF, CA > > is the only developer event you need to attend this year. > Jumpstart your > > developing skills, take BlackBerry mobile applications to > market and stay > > ahead of the curve. Join us from November 9 - 12, 2009. > Register now! > > http://p.sf.net/sfu/devconference > _______________________________________________ > > Wxdevide-devs mailing list > > Wxd...@li... > > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > > > > > -----Adjunto en línea a continuación----- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference > in SF, CA > is the only developer event you need to attend this year. > Jumpstart your > developing skills, take BlackBerry mobile applications to > market and stay > ahead of the curve. Join us from November 9 - 12, 2009. > Register now! > http://p.sf.net/sfu/devconference > -----Adjunto en línea a continuación----- > > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > ____________________________________________________________________________________ ¡Obtén la mejor experiencia en la web! Descarga gratis el nuevo Internet Explorer 8. http://downloads.yahoo.com/ieak8/?l=e1 |
|
From: Nuklear Z. <nuk...@gm...> - 2009-10-26 07:46:38
|
i can't say i like the idea, i have used C::B enough to know that it works quite a bit differently and that only makes it all the more tempting to create devblocks not Dev-C++ in C++. i am working away from windows as a primary os because of what has happened in xp sp2 and vista. i need an ide i like to be fully comfortable, but c::b works for now. i also need a text editor, but i am already building it. i would use fedora a lot more, but every time i call up gnome edit i get pissed and remember just how much i need a better editor. its like MS super notebook, not like what i need. wine is good to a point, but i have run into issues with it in the past too. so, if looking at codeblocks plugin system will help speed things up, ok, but lets write out own code. i don't like the idea that they own part of our work. libraries are a different story, but... if we make a complete gui that is basically a working text editor while we work on the plugin system/manager then the program will be usefull even before its functional. it will give us time to create the plugin system to allow for the compiler and debugger and stuff too. we can speed that part when it comes by wrapping c::b plugins to work with wxDevIDE. then we can write out own makefile based compiler plugins and the ide will be useful sooner than it would have been.that is another idea. i figued out some of the completion problems i was having, i think i can make a workable api, but it is not finished like scintilla meant it to be i don't think. if we need more developers, lets get on sf and see if anyone is interested. we can put up a help wanted so people know. maybe the wxforum can help, any other ideas? we are the primary developers, we know the insides the best between us all, but we can only do so much in a given amount of time per each of us. will that make you feel better? oh, stc did add some functionality too, i merged it into my wxScintilla, but now that they are working on it, i think that stc is the right way to go for the official scintilla editor backend, using xstc of course. they changed the library name to wxscintilla, so that was a bit confusing at first, that is why i thought they had both in the source tree at first, probably why i was told that by someone too. offical wxScitilla is dead and might as well be ignored. i am keeping mine updated, because when i am done building my text editor i am going to hack wxScintila to optionally let the user set an image background and i can't have a textctrl base in the way. Nuklear On Sun, Oct 25, 2009 at 7:47 PM, Tony Reina <tb...@gm...> wrote: > It's certainly not a bad suggestion. Plus, it is a question that we will > probably get from many, many other people. > > Although I'm not opposed to the idea of just modifying Code::Blocks, my > purpose behind this project is to build an IDE from scratch just to get the > experience and satisfaction of doing so. To me, this is more about the > journey than the destination. > > I have no idea how long this project will take and haven't even given > consideration to timelines at this point (other than the timeline of when we > start). That's the reason I wanted to get version 7 of wxDev-C++ finished > before we started this. If it takes several years and we still don't have > anything useful, then at least we have wxDev-C++ out there. > > -Tony > > > > On Sun, Oct 25, 2009 at 5:52 PM, Esteban Aguilar B. <nab...@ya...>wrote: > >> Hi, in advance, please forgive me if someone has already suggested this >> (maybe even I could have dismissed a similar suggestion, I just don't recall >> right now :D ). >> >> I don't want to introduce controversy at this point but I think this needs >> to be at least considered and discussed as an option. >> >> I have always had my concerns in regards to the effectiveness of starting >> an IDE again from 0, mostly because I've seen time and time again, open >> source projects get abandoned before actually being useful or close to >> "version 1.0" form. I don't want to be negative, but from all signs, at >> least as of now, we don't look to have enough man power to get this project >> to a useful state in an acceptable time frame.. (like less than 2 or 3 >> years). When I say "acceptable", I'm thinking, before our lives have a >> chance of changing enough that most of us are no longer able to keep working >> on this, while having at least a mature enough product that may attract some >> other devels to continue the work at that point, if such thing happens. >> >> Anyway, I know that having full control of the code from day zero would be >> great, but I'm thinking.... how about we grab Code::Blocks code, and try to >> morph its GUI to look and act just like we want wxDevIDE to be (alas, like >> wxDevCpp)? >> >> This software appears to have such strong foundation; it is popular, it >> has already plugin infrastructure built in, it has even many plugins >> already, and support for several compilers. I think it would be a little >> silly to replicate that work, if we care mostly for how it works for the end >> user... >> >> Someone could say that we could end up in a similar position as we were >> with wxDevCpp, in that we may en up depending from "others" work, but I >> think that the difference here is that we are now in wxWidgets/C++ camp, so >> we no longer have the delphi limitations for doing whatever changes we feel >> we need to do. For example, if they don't use wxScintilla or whatever for >> the editor, we can develop our one component. >> >> I think this approach has many benefits: First, MUCH faster and realistic >> time to come up with a 1.0 version. If this version actually sees the light >> of day, that means that our work would not be in vane. Second, better reuse >> of open source code. Also, our plugins, or other improvements could >> theoretically be retro-added to C::B, giving them some benefits. Fourth, we >> have potentially more developers able to develop plugins. I think there are >> more, but I don't want to extend this message much more. >> >> If this was already suggested, I would like to read again why we didn't >> like this option :) >> >> >> >> >> ____________________________________________________________________________________ >> ¡Obtén la mejor experiencia en la web! >> Descarga gratis el nuevo Internet Explorer 8. >> http://downloads.yahoo.com/ieak8/?l=e1 >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Wxdevide-devs mailing list >> Wxd...@li... >> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >> > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Tony R. <tb...@gm...> - 2009-10-26 03:47:31
|
It's certainly not a bad suggestion. Plus, it is a question that we will probably get from many, many other people. Although I'm not opposed to the idea of just modifying Code::Blocks, my purpose behind this project is to build an IDE from scratch just to get the experience and satisfaction of doing so. To me, this is more about the journey than the destination. I have no idea how long this project will take and haven't even given consideration to timelines at this point (other than the timeline of when we start). That's the reason I wanted to get version 7 of wxDev-C++ finished before we started this. If it takes several years and we still don't have anything useful, then at least we have wxDev-C++ out there. -Tony On Sun, Oct 25, 2009 at 5:52 PM, Esteban Aguilar B. <nab...@ya...>wrote: > Hi, in advance, please forgive me if someone has already suggested this > (maybe even I could have dismissed a similar suggestion, I just don't recall > right now :D ). > > I don't want to introduce controversy at this point but I think this needs > to be at least considered and discussed as an option. > > I have always had my concerns in regards to the effectiveness of starting > an IDE again from 0, mostly because I've seen time and time again, open > source projects get abandoned before actually being useful or close to > "version 1.0" form. I don't want to be negative, but from all signs, at > least as of now, we don't look to have enough man power to get this project > to a useful state in an acceptable time frame.. (like less than 2 or 3 > years). When I say "acceptable", I'm thinking, before our lives have a > chance of changing enough that most of us are no longer able to keep working > on this, while having at least a mature enough product that may attract some > other devels to continue the work at that point, if such thing happens. > > Anyway, I know that having full control of the code from day zero would be > great, but I'm thinking.... how about we grab Code::Blocks code, and try to > morph its GUI to look and act just like we want wxDevIDE to be (alas, like > wxDevCpp)? > > This software appears to have such strong foundation; it is popular, it has > already plugin infrastructure built in, it has even many plugins already, > and support for several compilers. I think it would be a little silly to > replicate that work, if we care mostly for how it works for the end user... > > Someone could say that we could end up in a similar position as we were > with wxDevCpp, in that we may en up depending from "others" work, but I > think that the difference here is that we are now in wxWidgets/C++ camp, so > we no longer have the delphi limitations for doing whatever changes we feel > we need to do. For example, if they don't use wxScintilla or whatever for > the editor, we can develop our one component. > > I think this approach has many benefits: First, MUCH faster and realistic > time to come up with a 1.0 version. If this version actually sees the light > of day, that means that our work would not be in vane. Second, better reuse > of open source code. Also, our plugins, or other improvements could > theoretically be retro-added to C::B, giving them some benefits. Fourth, we > have potentially more developers able to develop plugins. I think there are > more, but I don't want to extend this message much more. > > If this was already suggested, I would like to read again why we didn't > like this option :) > > > > > ____________________________________________________________________________________ > ¡Obtén la mejor experiencia en la web! > Descarga gratis el nuevo Internet Explorer 8. > http://downloads.yahoo.com/ieak8/?l=e1 > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > |
|
From: Esteban A. B. <nab...@ya...> - 2009-10-26 00:52:47
|
Hi, in advance, please forgive me if someone has already suggested this (maybe even I could have dismissed a similar suggestion, I just don't recall right now :D ).
I don't want to introduce controversy at this point but I think this needs to be at least considered and discussed as an option.
I have always had my concerns in regards to the effectiveness of starting an IDE again from 0, mostly because I've seen time and time again, open source projects get abandoned before actually being useful or close to "version 1.0" form. I don't want to be negative, but from all signs, at least as of now, we don't look to have enough man power to get this project to a useful state in an acceptable time frame.. (like less than 2 or 3 years). When I say "acceptable", I'm thinking, before our lives have a chance of changing enough that most of us are no longer able to keep working on this, while having at least a mature enough product that may attract some other devels to continue the work at that point, if such thing happens.
Anyway, I know that having full control of the code from day zero would be great, but I'm thinking.... how about we grab Code::Blocks code, and try to morph its GUI to look and act just like we want wxDevIDE to be (alas, like wxDevCpp)?
This software appears to have such strong foundation; it is popular, it has already plugin infrastructure built in, it has even many plugins already, and support for several compilers. I think it would be a little silly to replicate that work, if we care mostly for how it works for the end user...
Someone could say that we could end up in a similar position as we were with wxDevCpp, in that we may en up depending from "others" work, but I think that the difference here is that we are now in wxWidgets/C++ camp, so we no longer have the delphi limitations for doing whatever changes we feel we need to do. For example, if they don't use wxScintilla or whatever for the editor, we can develop our one component.
I think this approach has many benefits: First, MUCH faster and realistic time to come up with a 1.0 version. If this version actually sees the light of day, that means that our work would not be in vane. Second, better reuse of open source code. Also, our plugins, or other improvements could theoretically be retro-added to C::B, giving them some benefits. Fourth, we have potentially more developers able to develop plugins. I think there are more, but I don't want to extend this message much more.
If this was already suggested, I would like to read again why we didn't like this option :)
____________________________________________________________________________________
¡Obtén la mejor experiencia en la web!
Descarga gratis el nuevo Internet Explorer 8.
http://downloads.yahoo.com/ieak8/?l=e1
|
|
From: Nuklear Z. <nuk...@gm...> - 2009-10-21 06:16:10
|
i just found out that somebody finally updated stc. i don't know how recently, but until version 2.9 stc has not been worked on for a long time. it has been the same thing as wxScintilla in wxCode. they did update scintilla from 1.69 (the wxScintilla verision) to 1.70. now it is at 1.75 and they finally added the new languages. i could see some other more significant work that had been done to it as well, so things are brightening up for Scitnilla on the wx platform. i believe that they are work from the wxW2.6 release. in terms of wxScintilla which has been abandon and the older version of stc, the popup window api's don't seem fully completed. i found several things that didn't work when i tried to use them. so i am hoping the newer version will help take care of that. i have not had time to get into it too much. i tried to get xstc to build on fedora today, but the installation of wxWidgets is messed up and i couldnt' get anything to work. gcc4 is interesting having used gcc3 for so long, and i think maybe kinda a real pain too. Nuklear |
|
From: Tony R. <re...@al...> - 2009-10-19 02:18:06
|
Ok. You probably want to link this page to Esteban's wiki page ( http://sourceforge.net/apps/trac/wxdevide/wiki/APIdocs). Otherwise, there might be two sets of (different) API docs. -Tony On Sun, Oct 18, 2009 at 6:08 PM, Nuklear Zelph <nuk...@gm...>wrote: > http://sourceforge.net/apps/trac/wxdevide/wiki/EditorApi > > Nuklear > > > On Sun, Oct 18, 2009 at 5:25 PM, Tony Reina <re...@al...> wrote: > >> Can you provide the url? >> >> -Tony >> >> >> >> On Sun, Oct 18, 2009 at 3:46 PM, Nuklear Zelph <nuk...@gm...>wrote: >> >>> i have the current api on the editorapi page in trac now. >>> >>> Nuklear >>> >>> >>> On Sat, Oct 17, 2009 at 9:40 PM, Tony Reina <re...@al...> wrote: >>> >>>> Awesome. Can't wait to start playing with the code. >>>> >>>> -Tony >>>> >>>> >>>> >>>> On Sat, Oct 17, 2009 at 9:20 PM, Nuklear Zelph <nuk...@gm...>wrote: >>>> >>>>> got my old machine up and running with a new xp installation, helps to >>>>> find the installer disk. will need to ask an expert to program me a new bios >>>>> for the new mainboard, too bad. >>>>> >>>>> i'll get back on the api stuff now that i have the theoretical issues >>>>> worked out with the notebook. it should not be hard to work on the remaining >>>>> api's and i can get a first draft on the wiki and fine tune things later. >>>>> >>>>> Nuklear >>>>> >>>>> On Sat, Oct 17, 2009 at 9:56 AM, M Nealon <m.n...@wa...> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Oct 17, 2009 at 5:49 PM, Tony Reina <re...@al...>wrote: >>>>>> >>>>>>> >>>>>>>> Not too sure where I can best help, since you are all far better >>>>>>>> programmers than I, but I think I might concentrate on getting the >>>>>>>> internationalization and themes working (once Nuklear has the scintilla bit >>>>>>>> done) since this is probably the least code intensive part (obviously we >>>>>>>> would want to allow the user to reuse his own theme if possible). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> With your knowledge of devpaks, I could definitely use you for the >>>>>>> packman2extended and packmaker2extended development. The programs are >>>>>>> already written and working, but we could use a fresh set of eyes to work >>>>>>> through potential bugs and usability issues. If you have time, please think >>>>>>> of it. >>>>>>> >>>>>> >>>>>> >>>>>> Will look into it as time allows. >>>>>> >>>>>> Regards >>>>>> Mal >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>>>> is the only developer event you need to attend this year. Jumpstart >>>>>> your >>>>>> developing skills, take BlackBerry mobile applications to market and >>>>>> stay >>>>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>>>> http://p.sf.net/sfu/devconference >>>>>> _______________________________________________ >>>>>> Wxdevide-devs mailing list >>>>>> Wxd...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>>> is the only developer event you need to attend this year. Jumpstart >>>>> your >>>>> developing skills, take BlackBerry mobile applications to market and >>>>> stay >>>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>>> http://p.sf.net/sfu/devconference >>>>> _______________________________________________ >>>>> Wxdevide-devs mailing list >>>>> Wxd...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>>>> >>>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>> http://p.sf.net/sfu/devconference >>> _______________________________________________ >>> Wxdevide-devs mailing list >>> Wxd...@li... >>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>> >>> >> > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Wxdevide-devs mailing list > Wxd...@li... > https://lists.sourceforge.net/lists/listinfo/wxdevide-devs > > |
|
From: Nuklear Z. <nuk...@gm...> - 2009-10-19 01:08:51
|
http://sourceforge.net/apps/trac/wxdevide/wiki/EditorApi Nuklear On Sun, Oct 18, 2009 at 5:25 PM, Tony Reina <re...@al...> wrote: > Can you provide the url? > > -Tony > > > > On Sun, Oct 18, 2009 at 3:46 PM, Nuklear Zelph <nuk...@gm...>wrote: > >> i have the current api on the editorapi page in trac now. >> >> Nuklear >> >> >> On Sat, Oct 17, 2009 at 9:40 PM, Tony Reina <re...@al...> wrote: >> >>> Awesome. Can't wait to start playing with the code. >>> >>> -Tony >>> >>> >>> >>> On Sat, Oct 17, 2009 at 9:20 PM, Nuklear Zelph <nuk...@gm...>wrote: >>> >>>> got my old machine up and running with a new xp installation, helps to >>>> find the installer disk. will need to ask an expert to program me a new bios >>>> for the new mainboard, too bad. >>>> >>>> i'll get back on the api stuff now that i have the theoretical issues >>>> worked out with the notebook. it should not be hard to work on the remaining >>>> api's and i can get a first draft on the wiki and fine tune things later. >>>> >>>> Nuklear >>>> >>>> On Sat, Oct 17, 2009 at 9:56 AM, M Nealon <m.n...@wa...> wrote: >>>> >>>>> >>>>> >>>>> On Sat, Oct 17, 2009 at 5:49 PM, Tony Reina <re...@al...> wrote: >>>>> >>>>>> >>>>>>> Not too sure where I can best help, since you are all far better >>>>>>> programmers than I, but I think I might concentrate on getting the >>>>>>> internationalization and themes working (once Nuklear has the scintilla bit >>>>>>> done) since this is probably the least code intensive part (obviously we >>>>>>> would want to allow the user to reuse his own theme if possible). >>>>>>> >>>>>>> >>>>>>> >>>>>> With your knowledge of devpaks, I could definitely use you for the >>>>>> packman2extended and packmaker2extended development. The programs are >>>>>> already written and working, but we could use a fresh set of eyes to work >>>>>> through potential bugs and usability issues. If you have time, please think >>>>>> of it. >>>>>> >>>>> >>>>> >>>>> Will look into it as time allows. >>>>> >>>>> Regards >>>>> Mal >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>>> is the only developer event you need to attend this year. Jumpstart >>>>> your >>>>> developing skills, take BlackBerry mobile applications to market and >>>>> stay >>>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>>> http://p.sf.net/sfu/devconference >>>>> _______________________________________________ >>>>> Wxdevide-devs mailing list >>>>> Wxd...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>>>> >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >>>> is the only developer event you need to attend this year. Jumpstart your >>>> developing skills, take BlackBerry mobile applications to market and >>>> stay >>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >>>> http://p.sf.net/sfu/devconference >>>> _______________________________________________ >>>> Wxdevide-devs mailing list >>>> Wxd...@li... >>>> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >>>> >>>> >>> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Wxdevide-devs mailing list >> Wxd...@li... >> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs >> >> > |
5 messages has been excluded from this view by a project administrator.
