Home » Community » Coffee corner » Great (and funny) Linus' speach about GIT
|
Re: Great (and funny) Linus' speach about GIT [message #13494 is a reply to message #13491] |
Thu, 10 January 2008 22:58 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
mr_ped wrote on Thu, 10 January 2008 15:04 |
- I think uvs2 is bad idea, because it is non-standard, and works only on limited bandwidth for limited number of people. So I think the migration to different development model would be a step forward.
But it's up to Mirek to decide which direction that forward should take. SVN? GIT? Mercurial? Bazaar (versioning system)?
Plenty of choices, each does promise a bit different future, and require quite different policies and rules.
|
Well, that is the problem. I accept that uvs2 is no longer a good solution, but right now the migration effort does not seem worth it, especially when the options are many and none perfect... I am afraid of going from one unoptimal solution to another. At least, with uvs2, I know what to expect. And from time to time, we can fix problems too
Mirek
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13495 is a reply to message #13492] |
Fri, 11 January 2008 01:14 |
|
fudadmin
Messages: 1321 Registered: November 2005 Location: Kaunas, Lithuania
|
Ultimate Contributor Administrator |
|
|
mdelfede wrote on Thu, 10 January 2008 20:34 |
I'm quite happy with upp and theide as is it now.
|
I'm not. It's driving me mad. Core, CtrlCore, CtrlLib, RichEdit... Nearly all of them. Because if something somewhere is better I'd like to have it...
Things like messed up home directory with logs, usrlog files on Linux and BSD? Config files where? Cleaning configs? (Ok, I've noticed that yesterday's commit contains .upp/ in App.cpp but how long did it take? Why into core hardcoded dirs? Freedesktop standards configs? start HTML viewer on Posix? DirTree Ctrl? CodeEditor for other languages (including external syntax files)? Right click menus in theide CodeEditor? Switching root-user from theide and e.g using dummy pakages as smart directories for linux/bsd configs (usc macro Input auto parser is nice) and having Topic++ as smart documentation? Archlinux abs upp_aris package... UWord - RichEdit linking and not insertion of picture (including agg svg) files, HTML code generation for different standards, HTML parser - converter into qtf and backwards? Better stylesheets management and editing for websites design (connected with php templates)? Esc and macro extended funtions like "macro recorder-player", extended upt templates and their parameters entering, MenuCreator -templator package (I like that very much) , MacOS style agg docker-menu for Posix (including OpenBSD, and MirBSD), ByteCode compiler for interpreted languages, standalone Dialect interpreter with U++ GUI Ctrls, C++ OO gigabase database packages? Using theide for Symbian60- epoc Nokia? ...
Have you got all that? I have or had. Messy as hell. Most of those I had working "as a proof of concept" level. But then it comes catching up with new official versions and merging...
And then I think if Mirek is so effective and can write such a clean and practically bugless code and he is using Uvs2... IT must be good.
...
And then I know that there people who work on the same things. Woldn't be better to share such things even they are very small and not perfectly or (at all) finished?
mdelfede wrote on Thu, 10 January 2008 20:34 |
Maybe an added mercurial repository for code experiments on a centralized ftp server would be a good stuff, but then it needs a mantainer to keep it in sync with uvs2 as I'm trying to do now with svn repo. It's not an hard job, but it needs a person that can do it almost daily, to be effective.
If there's a volunteer here to do it, it's not too hard to find a free ftp server, build a mercurial repo synced with svn and open it to all.
Ciao
Max
|
I've got ftp server with 10 accounts 10gb/month bandw now. (In a few days or weeks could recover another, bigger one if needed)
I'm a voluteer who can do that job almost daily.
So mercurial repo?
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13496 is a reply to message #13495] |
Fri, 11 January 2008 09:03 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
fudadmin wrote on Thu, 10 January 2008 19:14 |
I'm not. It's driving me mad. Core, CtrlCore, CtrlLib, RichEdit... Nearly all of them. Because if something somewhere is better I'd like to have it...
Things like messed up home directory with logs, usrlog files on Linux and BSD? Config files where? Cleaning configs? (Ok, I've noticed that yesterday's commit contains .upp/ in App.cpp but how long did it take? Why into core hardcoded dirs? Freedesktop standards configs? start HTML viewer on Posix? DirTree Ctrl? CodeEditor for other languages (including external syntax files)? Right click menus in theide CodeEditor? Switching root-user from theide and e.g using dummy pakages as smart directories for linux/bsd configs (usc macro Input auto parser is nice) and having Topic++ as smart documentation? Archlinux abs upp_aris package... UWord - RichEdit linking and not insertion of picture (including agg svg) files, HTML code generation for different standards, HTML parser - converter into qtf and backwards? Better stylesheets management and editing for websites design (connected with php templates)? Esc and macro extended funtions like "macro recorder-player", extended upt templates and their parameters entering, MenuCreator -templator package (I like that very much) , MacOS style agg docker-menu for Posix (including OpenBSD, and MirBSD), ByteCode compiler for interpreted languages, standalone Dialect interpreter with U++ GUI Ctrls, C++ OO gigabase database packages? Using theide for Symbian60- epoc Nokia? ...
|
Aris, what makes you think that that you need anything to get these?
Why do not you just sit and start coding?
If you need more developers participate, fine, you have Bazaar SVN repo.
BTW, I am still waiting for a reasonable AGG package without a catch. Something I can download, unpack to 1-3 packages, move into my uppdev nest and start testing. Something like extended testcase. It would be helpful, if for nothing else, to bechmark the performance of new planned painting module...
Mirek
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13497 is a reply to message #13175] |
Fri, 11 January 2008 09:43 |
mr_ped
Messages: 825 Registered: November 2005 Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
"Why do not you just sit and start coding?"
I thought he was listing things he already *did*.
(probably not clean enough to be merged back into official upp to just send you testing package)
----
... about mirrored svn, mercurial (and whatever you like, I think after the SVN is finally synced with uvs2 (great!), this is no more problem of UPP crew, anybody can create whatever repository likes, and sync with synced SVN ... souds ugly? It will be ugly. But there's not much more there can be done about it without radical change in upp core team, i.e. defining new philosophy/policies of maintaining upp project, choosing the tools and migrating from uvs there).
As I wrote above, Mirek tends to change core sources a lot, he definitely likes to refactor code anytime he doesn't feel happy about it. (that's great actually)
So whenever you fork from official upp, do your own changes on let's say private branch in svn, if it takes you more than 2-3 months, you are facing ugly task of merging back to recent upp, especially if you don't merge continuously trough those 2 months.
If you work on something quite independent, this is not a real deal, if you work on something like that X11 DHctrl, it will probably make the process of "finishing" package much harder, as you are trying to hit a moving target.
Merging continuously is something what makes your base for that experiment (potentially) unstable and (for sure) "moving", and while upp is usually quite stable after refactoring, you may stop feeling safe.. if you don't feel safe, you may start to look for (your) bugs in upp code .. you will lose time, confidence, and get worser code in the end.
(just read some basics about Test Driven Development and the reasoning behind it, most of the TDD advocates say the improved confidence improves everything... coding speed, code quality, you name it. From my limited experience with TDD I can only agree with that, the confidence and ability to focus on single problem had earthshaking effect on my laziness and productivity, which has been quite low recent years on my side)
Also keep in mind Mirek does not announce what he is working on, so many bigger inner refactorings happen pretty much overnight in uvs2 without any hint they will appear. Had you finished your package on evening, wanting to give it another test and morning and send to Mirek as finished? It may be well obsolete at morning.
All these apply big time only to upp core development itself, Mirek's notice about giving more (but carefully) write permissions will lead to "low number of core developers", just as I said before. This is not a horrible thing, after all the upp has been like this for years and it does progress forward, so it's certainly a working philosophy/policy.
But it may look like some personal project for years due to this (and not like a serious development platform ... and while upp has got it's share of problems if you want it to exactly fit your biz needs, Mirek's own living proves the platform *is* viable and serious for commercial use already).
If you are doing work outside of core, you are usually bound only to upp API, and while that one does change quite a lot too, you can usually "port" your obsolete source to fresh upp version within minutes or hours, so you can work on stable base, and merge with latests only sometimes. Especially if you work with old stable parts of API, you are unlikely to hit any of these things I write above about.
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13502 is a reply to message #13497] |
Fri, 11 January 2008 11:12 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
mr_ped wrote on Fri, 11 January 2008 09:43 |
... about mirrored svn, mercurial (and whatever you like, I think after the SVN is finally synced with uvs2 (great!), this is no more problem of UPP crew, anybody can create whatever repository likes, and sync with synced SVN ... souds ugly? It will be ugly. But there's not much more there can be done about it without radical change in upp core team, i.e. defining new philosophy/policies of maintaining upp project, choosing the tools and migrating from uvs there).
|
That's right for people be in sync with latest devel, not for people wanting to contribute. But again that's an hard stuff.
I guess Mirek must choose between having a tight control of his sources OR opening it to more developers. And, as he uses upp to develop commercial apps (and, I guess, to earn money of them) his choice must be the first one.
Quote: |
As I wrote above, Mirek tends to change core sources a lot, he definitely likes to refactor code anytime he doesn't feel happy about it. (that's great actually)
|
And that's needed to stay tuned with, for example, new stuffs like windows Vista (beurk!). That, of course, because of some lack of code modularity in upp, to some extent. But again I can understand Mirek, adding more code modularity would mean a major rewrite of upp.... I wouldn't do it.
Quote: |
So whenever you fork from official upp, do your own changes on let's say private branch in svn, if it takes you more than 2-3 months, you are facing ugly task of merging back to recent upp, especially if you don't merge continuously trough those 2 months.
If you work on something quite independent, this is not a real deal, if you work on something like that X11 DHctrl, it will probably make the process of "finishing" package much harder, as you are trying to hit a moving target.
|
That's the real problem. Contributors get an hard work to sync with upp continuosly before changes are merged in main three.
But I don't see an easy solution to that, without loosing control on code quality.
I think that we must distinguish betweeen 2 cases :
1- Changes to upp core stuffs
2- Adding new functionalities
For the first point, you'd need a different developing model, with all kind of problems it brings. I'd leave that like it is now, asking Mirek to insert patches inside main three after extensive testing.
The second point would be much easier for external developers IF
some sort of plugin system would be added to upp.
I'd like very much such a system... a plugin system with a SKD to develop external add-ons.
Ciao
Max
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13503 is a reply to message #13497] |
Fri, 11 January 2008 12:10 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
mr_ped wrote on Fri, 11 January 2008 03:43 |
But it may look like some personal project for years due to this (and not like a serious development platform ... and while upp has got it's share of problems if you want it to exactly fit your biz needs, Mirek's own living proves the platform *is* viable and serious for commercial use already).
If you are doing work outside of core, you are usually bound only to upp API, and while that one does change quite a lot too, you can usually "port" your obsolete source to fresh upp version within minutes or hours, so you can work on stable base, and merge with latests only sometimes. Especially if you work with old stable parts of API, you are unlikely to hit any of these things I write above about.
|
Well, how do you think Qt is being developed?
Sure, there is a company behind instead of "core team", but other than that, I see not much difference.
(BTW, in fact, there is a "company" behind U++ too:
http://www.justice.cz/xqw/xervlet/insl/report?sysinf.vypis.C EK=314384&sysinf.vypis.rozsah=aktualni&sysinf.@typ=t ransformace&sysinf.@strana=report&sysinf.vypis.typ=X HTML&sysinf.vypis.klic=d391b6b69b0227d4dd916e94deba582f& amp;sysinf.spis.@oddil=C&sysinf.spis.@vlozka=59328&s ysinf.spis.@soud=M%ECstsk%FDm%20soudem%20v%20Praze&sysin f.platnost=11.01.2008
)
Mirek
|
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13505 is a reply to message #13502] |
Fri, 11 January 2008 12:27 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
mdelfede wrote on Fri, 11 January 2008 05:12 |
I think that we must distinguish betweeen 2 cases :
1- Changes to upp core stuffs
2- Adding new functionalities
For the first point, you'd need a different developing model, with all kind of problems it brings. I'd leave that like it is now, asking Mirek to insert patches inside main three after extensive testing.
The second point would be much easier for external developers IF
some sort of plugin system would be added to upp.
I'd like very much such a system... a plugin system with a SKD to develop external add-ons.
|
It is nice how spending a while with CtrlCore changes the view, is not it?
I agree 100% with you. I also think that second point is already in progress, in last .dev the bazaar was the part of release, although not very well integrated.
The U++ is designed to be very modular. There should be a little problem with extending it by adding packages.
However, one problem I have noticed over years is that quite often, somebody contributes some code and then goes silent for a long time (hi, Aris!). This makes things difficult to integrate into 'uppsrc' - we are working hard to maintain these core parts, no energy left to maintain extensions...
So Bazaar seems quite OK for now. There a is clear distinction between Bazaar and uppsrc; and nobody will make me responsible for that code And you can contribute via SVN too.
Mirek
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13508 is a reply to message #13505] |
Fri, 11 January 2008 14:05 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
luzr wrote on Fri, 11 January 2008 12:27 |
mdelfede wrote on Fri, 11 January 2008 05:12 |
I think that we must distinguish betweeen 2 cases :
1- Changes to upp core stuffs
2- Adding new functionalities
For the first point, you'd need a different developing model, with all kind of problems it brings. I'd leave that like it is now, asking Mirek to insert patches inside main three after extensive testing.
The second point would be much easier for external developers IF
some sort of plugin system would be added to upp.
I'd like very much such a system... a plugin system with a SKD to develop external add-ons.
|
It is nice how spending a while with CtrlCore changes the view, is not it?
|
eheheheheheh... I knew it before, but you know, I like to try stuffs by myself
Quote: |
I agree 100% with you. I also think that second point is already in progress, in last .dev the bazaar was the part of release, although not very well integrated.
The U++ is designed to be very modular. There should be a little problem with extending it by adding packages.
|
With 'plugin system' I mean a dll/.so loader, a sdk and some documented plugin api, that will allow to write some plugins in form of dll/.so without the need of recompile theide (which is not a big concern) and without the need of updating the add-ons on each core change (which IS a big concern).
Quote: |
However, one problem I have noticed over years is that quite often, somebody contributes some code and then goes silent for a long time (hi, Aris!). This makes things difficult to integrate into 'uppsrc' - we are working hard to maintain these core parts, no energy left to maintain extensions...
|
The 'plugin mechanics' would solve at least 80% of this problem, leaving to core developers just the mantainment of plugin sdk. As is it now you must integrate each extension in theide/core... that is time consuming.
Quote: |
So Bazaar seems quite OK for now. There a is clear distinction between Bazaar and uppsrc; and nobody will make me responsible for that code And you can contribute via SVN too.
|
Besides of plugins, bazaar *would* be good having a separate svn with public access for it, so it could become a place where everyone could contribute without limitations. It would be interesting to find an alternate svn hosting place for it...
Ciao
Max
EDIT : back to core 'fiddling', for me it was *very* difficult because I had to try to understand how it works.... And, I must say it, classes/function names and (missing) comments didn't make my life easy !
[Updated on: Fri, 11 January 2008 14:08] Report message to a moderator
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13510 is a reply to message #13508] |
Fri, 11 January 2008 14:29 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
mdelfede wrote on Fri, 11 January 2008 08:05 |
luzr wrote on Fri, 11 January 2008 12:27 |
mdelfede wrote on Fri, 11 January 2008 05:12 |
I think that we must distinguish betweeen 2 cases :
1- Changes to upp core stuffs
2- Adding new functionalities
For the first point, you'd need a different developing model, with all kind of problems it brings. I'd leave that like it is now, asking Mirek to insert patches inside main three after extensive testing.
The second point would be much easier for external developers IF
some sort of plugin system would be added to upp.
I'd like very much such a system... a plugin system with a SKD to develop external add-ons.
|
It is nice how spending a while with CtrlCore changes the view, is not it?
|
eheheheheheh... I knew it before, but you know, I like to try stuffs by myself
Quote: |
I agree 100% with you. I also think that second point is already in progress, in last .dev the bazaar was the part of release, although not very well integrated.
The U++ is designed to be very modular. There should be a little problem with extending it by adding packages.
|
With 'plugin system' I mean a dll/.so loader, a sdk and some documented plugin api, that will allow to write some plugins in form of dll/.so without the need of recompile theide (which is not a big concern) and without the need of updating the add-ons on each core change (which IS a big concern).
|
While plugin system would be fine (but is pretty difficult with C++ in fact), I do not see how it is going to fix the problem, or more precisily, how it is better than packages.
Mirek
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13511 is a reply to message #13505] |
Fri, 11 January 2008 15:38 |
|
fudadmin
Messages: 1321 Registered: November 2005 Location: Kaunas, Lithuania
|
Ultimate Contributor Administrator |
|
|
[quote title=luzr wrote on Fri, 11 January 2008 11:27
...
However, one problem I have noticed over years is that quite often, somebody contributes some code and then goes silent for a long time (hi, Aris!).
Mirek
[/quote]
Maybe they were not entirely happy with something related?
Ok, I don't want to waste too much time analyzing and explaining all possible reasons...
But... One thing I maybe (or maybe not ) regret that you provoked me to get involved with that EyeCare comparison article and I went deep into web things. Because I'm a perfectionist and I wanted that comparison to be like I imagine... In quirks mode. Something like yahoo widgets and for different browsers with splitters, charts, buttons etc. (one conclusion - all browsers are bad and slow but MS Internet Explorer is the fastest ). Because, how otherwise "ugly stupid" (using Linus words) wxwidgets fans would grasp that 282 lines is much less than 838 (and mostly ?.? times shorter...) from this kind of interface http://www.arilect.com/upp/articles/compare_EyeCare/index.ht m ... An improved variant with some really nice graphics design I incorporated into Xaraya's http://www.xaraya.org/ php templates and wrote some "small" helpers in U++ for that kind of developement. And? Then 2 or even more months I spend recovering pieces from my hard disk (No 4 in 2 years). Etc., etc. Doesn't matter. I'll publish that improved thing one day, anyway (but don't ask me when).
1. What matters is that a developer can't rely on one computer! 2. It's too expensive not to have a separate file server or servers.
3. And to work with a messy version control or without any is a (... put your worst word here )
So - advice me - from where, what and where to install and how to keep up in synchro with uppdev and do merges with less pain. Then expect my contributions very soon.
Aris
P.S. And mr_ped and mdelfede are very clever.
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13512 is a reply to message #13510] |
Fri, 11 January 2008 16:09 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
luzr wrote on Fri, 11 January 2008 14:29 |
While plugin system would be fine (but is pretty difficult with C++ in fact), I do not see how it is going to fix the problem, or more precisily, how it is better than packages.
|
It isn't better, is just different.
Packages are *very* good for developers, plugins are the best for users.
With a package you must :
- drop source inside upp tree
- recompile theide
AND, not having a stable interface, usually you must also mantain the extension along upp changes.
With a plugin, you get a dll (or .so), you just drop it on a plugin folder and you have a ready to use extension.
AND, if you've got a stable and documented sdk, you must recompile plugin only on major ide changes (i.e. changes on binary format, compiler, ecc), which does a big difference, IMHO.
That was the cause of success of Borland products, with their components.
We spoke about that a time ago, about the way controls are made and drawn. Your choice of having ontrols as part of upp (and drawn by esc code on layout editor) is not bad, but then if you add a control you must recompile the full ide *and* write an esc code for layout editor. Double job....
About the problems of c++, I don't see any big caveat.
Of course, the plugin must be recompiled for every compiler choice, but that's true even with c if you change platform.
BTW, plugins are inside code::blocks and they work.
OTOH, if you're concerned about c++ problems, you could make a c interface both on theide side and on sdk side... that would open the plugin system to other languages too.
Ciao
Max
|
|
|
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13518 is a reply to message #13516] |
Fri, 11 January 2008 18:19 |
mdelfede
Messages: 1307 Registered: September 2007
|
Ultimate Contributor |
|
|
luzr wrote on Fri, 11 January 2008 18:04 |
mdelfede wrote on Fri, 11 January 2008 10:09 |
OTOH, if you're concerned about c++ problems, you could make a c interface both on theide side and on sdk side... that would open the plugin system to other languages too.
|
Actually, each time I start thinking in this direction, I end with plugin as separate process and using something like Corba or SOAP for interface...
|
Well, it seems to me a bit complicated for the scope, but....
Quote: |
As Zsolt pointed out, this is incorrect. Plus, in .dll style components, you have to write some "development time" code too. So the only difference is that in U++, you write "development" code as .usc script...
|
well, that's true. But in .dll style you're forced to do if ( ), with esc code you end up with half finished components.
But again, as components are used only by developers, I agree that your way is not bad at all (of course, it doesn't allow closed source components).
For plugins I see it a bit different.
BTW, I've got a small question about writing an enhancement to theide.... I want to make a 'reformat code' menu point, using astyle. How (if it's simple to tell me...) should I handle the editor change and the undo stuff ? My code should read the full buffer as a string and write it again inside editor once formatted.
Ciao
Max
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13520 is a reply to message #13518] |
Fri, 11 January 2008 18:37 |
|
mirek
Messages: 13985 Registered: November 2005
|
Ultimate Member |
|
|
mdelfede wrote on Fri, 11 January 2008 12:19 |
luzr wrote on Fri, 11 January 2008 18:04 |
mdelfede wrote on Fri, 11 January 2008 10:09 |
OTOH, if you're concerned about c++ problems, you could make a c interface both on theide side and on sdk side... that would open the plugin system to other languages too.
|
Actually, each time I start thinking in this direction, I end with plugin as separate process and using something like Corba or SOAP for interface...
|
Well, it seems to me a bit complicated for the scope, but....
Quote: |
As Zsolt pointed out, this is incorrect. Plus, in .dll style components, you have to write some "development time" code too. So the only difference is that in U++, you write "development" code as .usc script...
|
well, that's true. But in .dll style you're forced to do if ( ), with esc code you end up with half finished components.
But again, as components are used only by developers, I agree that your way is not bad at all (of course, it doesn't allow closed source components).
For plugins I see it a bit different.
BTW, I've got a small question about writing an enhancement to theide.... I want to make a 'reformat code' menu point, using astyle. How (if it's simple to tell me...) should I handle the editor change and the undo stuff ? My code should read the full buffer as a string and write it again inside editor once formatted.
Ciao
Max
|
Generally, undo works on pretty low level - there are only two basic operations supported by editor - insert and remove. Both store records to undo queue.
In your case it would mean that if you perform your replace as "remove" / "insert", it should work... (I guess you will want to support selection reformatting as well, so this is more than natural IMO).
Mirek
|
|
|
|
Re: Great (and funny) Linus' speach about GIT [message #13523 is a reply to message #13518] |
Fri, 11 January 2008 19:03 |
zsolt
Messages: 698 Registered: December 2005 Location: Budapest, Hungary
|
Contributor |
|
|
mdelfede wrote on Fri, 11 January 2008 18:19 |
But again, as components are used only by developers, I agree that your way is not bad at all (of course, it doesn't allow closed source components).
|
I think, this is not true as well. Just check MySql or PostgreSQL package. They are a thin layer on top of a DLL. You can always do the same, if you want to provide a closed source package. (Maybe this could be mentioned in a HOWTO.)
mdelfede wrote on Fri, 11 January 2008 18:19 |
BTW, I've got a small question about writing an enhancement to theide.... I want to make a 'reformat code' menu point, using astyle. How (if it's simple to tell me...) should I handle the editor change and the undo stuff ? My code should read the full buffer as a string and write it again inside editor once formatted.
|
This can be a good starting point for you to implement a source manipulator plugin interface. It could be very simple, as it could work on simple "C" string buffers.
The plugin interface would declare a .dll (or .so) in a header file something like:
extern "C"{
const char* ManipulateSourcecode(const char*);
void FreeWorkingBuffer();
const char* GetPluginName();
}
|
|
|
Goto Forum:
Current Time: Sun Jun 16 14:55:27 CEST 2024
Total time taken to generate the page: 0.03115 seconds
|