wxdevide-devs

[Wxdevide-devs] doc manager and notebook

[Nuklear Z. <nuk...@gm...>]

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

Re: [Wxdevide-devs] doc manager and notebook

[Tony R. <re...@al...>]

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&#174; 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
>
>

Re: [Wxdevide-devs] doc manager and notebook

[Esteban A. B. <nab...@ya...>]

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&#174; 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

Re: [Wxdevide-devs] doc manager and notebook

[Nuklear Z. <nuk...@gm...>]

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&#174; 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
>>>
>>>
>>
>

Re: [Wxdevide-devs] doc manager and notebook

[Tony R. <re...@al...>]

> 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

Re: [Wxdevide-devs] doc manager and notebook

[Nuklear Z. <nuk...@gm...>]

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
>
>

Re: [Wxdevide-devs] doc manager and notebook

[Tony R. <re...@al...>]

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&#174; 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
>
>

Re: [Wxdevide-devs] doc manager and notebook

[Nuklear Z. <nuk...@gm...>]

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&#174; 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
>>>
>>>
>>
>