Batch Queue Manager
Locked
12
12
 
|
Good evening.
I doing some experiments with very-draft implementation of "External Tools" in BQM and I have reach a little ambiguity. 1. As I see it is not possible to run BQM renaming without applying any effect. I.e. "Just rename a couple of photo". RIght?
2. "Rename" action realized and binded to menu/hotkey in manual way(by creation KAction and specific slot in DigikamImageView, which is the main central widget in digikam). Right? 3. As Gilles Caulier said: "Definitively, BQM is the future for batch processing, not KIPI. The only interest of KIPI currently is web export tools that doesn't exists in BQM." - Does KSnapshot or Gwenview are using(will use) BQM? - Does BQM is planing to be exported out of Digikam and reused by other apps? - Why 'future' is not in extending KIPI with batch parallel processing feature and integrate it in other image-related apps?
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
2013/10/30 Yuri Samoilenko <[hidden email]>:
> Good evening. > > I doing some experiments with very-draft implementation of "External Tools" > in BQM and I have reach a little ambiguity. > > 1. As I see it is not possible to run BQM renaming without applying any > effect. I.e. "Just rename a couple of photo". RIght? yes. you need to assign at least one tool in queue. If you want only to perform files renaming this option already exist outside BQM... > > 2. "Rename" action realized and binded to menu/hotkey in manual way(by > creation KAction and specific slot in DigikamImageView, which is the main > central widget in digikam). Right? This widget is the same everywhere. In fact all advanced renaming operation implementation are shared. Look into utilities/advancerename for details. > > 3. As Gilles Caulier said: > "Definitively, BQM is the future for batch processing, not KIPI. The only > interest of KIPI currently is web export tools that doesn't exists in BQM." > > - Does KSnapshot or Gwenview are using(will use) BQM? no. and we (digiKam team) don't care about others applications, due to uninterested these teams about kipi-plugins project (nobody contribute to kipi-plugins excepted digiKam developers) Typically, kipi-plugins batch tools are always present in others application. Plugins loading will be just disabled in digiKam > - Does BQM is planing to be exported out of Digikam and reused by other > apps? No. It's a pure digiKam core implementation. It's already difficult to stabilize it. We don't need to export it to increase again the complexity. We have already spare a lots of time with libkipi/kipi-plugins without any gain (as more developers from other kipi host applications help us to improve it). Don't forget that all libkipi/kipi-plugins come from digiKam core originally... I know well, i do it in first years of the project. > - Why 'future' is not in extending KIPI with batch parallel processing > feature and integrate it in other image-related apps? It's already done for some tools, as DNGConverter, RAWConverter, Panorama, expoblending, sendimages... but not all tools are patched. It's take time and it's complex to debug. If i found good students to do it, well why not, but no more. Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
OK, thank you for answers. I understand the dificulity and complexity of maintanence integrated(reusable) sollutions. I have using kipi import/export plugins in other application(gwenview) often, and I hope I have growth(in expirience) enough to help The Open Source community.
2013/10/31 Gilles Caulier <[hidden email]> 2013/10/30 Yuri Samoilenko <[hidden email]>: _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
2013/10/31 Yuri Samoilenko <[hidden email]>:
> OK, thank you for answers. I understand the dificulity and complexity of > maintanence integrated(reusable) sollutions. I have using kipi import/export > plugins in other application(gwenview) often, and I hope I have growth(in > expirience) enough to help The Open Source community. And you are welcome. If you want to help us to develop and maintain code seriously, i recommend you to take a developer account to KDE git repository. This depend how you want to contribute. Note that opensource is so far the best way to learn computer science technology. I know the subject. I'm teacher in a computer science engineer school in France (my 2nd job, look details to my G+ account). What's your skill exactly ? Best Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
I'am a developer for Russion NAVY in field of Digital Signal Processing(for the soul). Also I have lot of experience in "commercial work" as C++ programmer(for the money :) )
I have very experienced in Qt(began from Qt2 through Qt3 to Qt4), in Linux and opensource, have some kernel(custom wideband reciever drivers) development practice and even(!) windows development experience :)
I'am working for NAVY(1st job mostly in C++) and for private firm(2nd job mostly Ruby on Rails webdev).
I'am 28 years old :) 2013/10/31 Gilles Caulier <[hidden email]> 2013/10/31 Yuri Samoilenko <[hidden email]>: _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
On Thu, Oct 31, 2013 at 7:17 PM, Yuri Samoilenko <[hidden email]> wrote:
That's pretty impressive, welcome to KDE! :) Cheers -- Martin Klapetek | KDE Developer
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Yuri,
Your skill is interesting... I started to review your patch from https://git.reviewboard.kde.org/r/113519/ About your kipi-plugins patch, it will be good to include your code in a dedicated git branch. For that ask a developer account to KDE admin, as i explained before... Look here for details : http://techbase.kde.org/Contribute/Get_a_Contributor_Account Best Gilles Caulier 2013/10/31 Martin Klapetek <[hidden email]>: > On Thu, Oct 31, 2013 at 7:17 PM, Yuri Samoilenko <[hidden email]> wrote: >> >> I'am a developer for Russion NAVY in field of Digital Signal >> Processing(for the soul). Also I have lot of experience in "commercial work" >> as C++ programmer(for the money :) ) >> I have very experienced in Qt(began from Qt2 through Qt3 to Qt4), in Linux >> and opensource, have some kernel(custom wideband reciever drivers) >> development practice and even(!) windows development experience :) >> >> I'am working for NAVY(1st job mostly in C++) and for private firm(2nd job >> mostly Ruby on Rails webdev). >> >> I'am 28 years old :) > > > That's pretty impressive, welcome to KDE! :) > > Cheers > -- > Martin Klapetek | KDE Developer > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Gilles Caulier: About your kipi-plugins patch, it will be good to include your code in a dedicated git branch. For that ask a developer account to KDE admin, What means "dedicated"? A tech base says: "A KDE commit account allows you to write to nearly anywhere in the KDE repositories" _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
On Mon, Nov 4, 2013 at 9:00 PM, Yuri Samoilenko <[hidden email]> wrote:
It means developing this feature in an own git branch, see https://www.atlassian.com/git/tutorial/git-branches for some tutorial (or google up "branches in git"). Then you can push this branch to the KDE repository where other developers can have a look and test it out without any changes to the master branch (which is the "main" branch everyone uses).
Cheers Martin Klapetek | KDE Developer
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
2013/11/5 Martin Klapetek <[hidden email]>
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Gilles Caulier-4
> Hi Yuri, > Your account has now been converted to a developer account. > The username for SVN is "yurisamoilenko". Please find instructions attached. I have developer account now :)
2013/11/4 Gilles Caulier <[hidden email]> About your kipi-plugins patch, it will be good to include your code in _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
ok. fine.
Please put your BQM patch in a dedicated branch of digiKam repository. Look my instructions that i write for students this summer : http://community.kde.org/Digikam/GSoC2013#Repositories.2C_Branching.2C_and_Dates Take a care that digiKam SC (root) is a repository, kipi-plugins is another one, digiKam (core) another ne too, etc... Just process core (digiKam) to create a branch, apply your patch and commit. It will be easy to sync your branch with master and later, when your code will be stabilized and tested, to sync back from your branch to master for release. Yu will see also in link given before a release plan for 4.0.0. This one is of course in the way. It will be nice to see your patch ready for beta2 or beta3. Gilles Caulier 2013/11/10 Yuri Samoilenko <[hidden email]>: >> Hi Yuri, > >> Your account has now been converted to a developer account. >> The username for SVN is "yurisamoilenko". Please find instructions >> attached. > > I have developer account now :) > > 2013/11/4 Gilles Caulier <[hidden email]> >> >> About your kipi-plugins patch, it will be good to include your code in >> a dedicated git branch. For that ask a developer account to KDE admin, >> as i explained before... Look here for details : > > > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Hello. Please put your BQM patch in a dedicated branch of digiKam repository. I have pushed my branch as remotes/origin/development/externaltools but for the first time - squashed to one commit. Take a care that digiKam SC (root) is a repository, kipi-plugins is What about branch manipulating strategy? 1. Is rebasing to master allowed in development branches? 2. All development branches(tested) will be merget to master?
3. What about bug fixes(not related to ET)? Can I create separate branch for fixing branch? 4. I have found bug: "Target Album" in Target tab is not working in master branch(without ET) when two or more queue present - all processed pictures puts in last selected album. I need to create request in bugtracker or I can fix bug without it(in separate branch)? What about review board? Can I close request? _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
2013/11/10 Yuri Samoilenko <[hidden email]>:
> Hello. > >> Please put your BQM patch in a dedicated branch of digiKam repository. >> Look my instructions that i write for students this summer : > > > I have pushed my branch as remotes/origin/development/externaltools but for > the first time - squashed to one commit. > Yes, i see it. I'm registered to commit filter : http://commitfilter.kde.org/ Like this i see all commit done by all contributors through email. > >> >> Take a care that digiKam SC (root) is a repository, kipi-plugins is >> another one, digiKam (core) another ne too, etc... Just process core >> (digiKam) to create a branch, apply your patch and commit. It will be >> easy to sync your branch with master and later, when your code will be >> stabilized and tested, to sync back from your branch to master for >> release. > > > What about branch manipulating strategy? > 1. Is rebasing to master allowed in development branches? You can sync (you must) this branch with master changes to have your branch updated in time. Later, when your code branch will be hacked, we will sync back from your branch to master. The goal is do it before 4.0.0 beta 2. > 2. All development branches(tested) will be merget to master? Yes, sure. > 3. What about bug fixes(not related to ET)? Can I create separate branch for > fixing branch? No need if code changes are not too intrusive and quickly testable. In general, making patch attached to relevant bugzilla entry is enough. I don't like reviewboard. This require to manage too tools, where only one is enough to control bug fixes : bugzilla. > 4. I have found bug: > "Target Album" in Target tab is not working in master branch(without ET) > when two or more queue present - all processed pictures puts in last > selected album. > I need to create request in bugtracker or I can fix bug without it(in > separate branch)? > First check if bugzilla do not contain an entry about this problem. If i remember, ther is something about. In bugzilla all digiKam project is divided in sub section. There is one about BQM. If there is no entry about, create new one, and attach a patch as well. No need reviewboard (forget this tool) > > What about review board? Can I close request? Let's open this entry for the moment, we will close it when you code will be tested and merged back from branch to master. For this week end, i'm with my familly. I go back at home monday evening. I will review all your new branch and code tuesday evening. Don't forget that i'm in stop disease for few month due to my car crash and i will have a lots of free time to play with code (:=))) Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Good evening
Nice stuff thx.
I mean that if I will use git rebase(not merge) to master then other developers who want to track my branch(I mean any development branch) can't fast-forward changes. They will forced to use 'force update', but rebased branch will have more plain(simple) commit history. In other word can I consider development branches as 'private'(allow rebase and breaking fast-forward) or it must be considered as 'public'(no rebase allowed only git merge).
ok For this week end, i'm with my familly. I go back at home monday ok - I'm in no hurry. The first of november(9 days ago) my daughter was born and now I can always find how to spend time :) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
2013/11/10 Yuri Samoilenko <[hidden email]>:
> Good evening > >> Yes, i see it. I'm registered to commit filter : >> http://commitfilter.kde.org/ >> Like this i see all commit done by all contributors through email. > > > Nice stuff thx. > > >> > What about branch manipulating strategy? >> > 1. Is rebasing to master allowed in development branches? >> >> You can sync (you must) this branch with master changes to have your >> branch updated in time. > > > I mean that if I will use git rebase(not merge) to master then other > developers who want to track my branch(I mean any development branch) can't > fast-forward changes. They will forced to use 'force update', but rebased > branch will have more plain(simple) commit history. In other word can I > consider development branches as 'private'(allow rebase and breaking > fast-forward) or it must be considered as 'public'(no rebase allowed only > git merge). Public, because i will review your code and commit fixes... > > >> >> No need if code changes are not too intrusive and quickly testable. In >> general, making patch attached to relevant bugzilla entry is enough. I >> don't like reviewboard. This require to manage too tools, where only >> one is enough to control bug fixes : bugzilla. >> >> No need reviewboard (forget this tool) > > > ok > > >> For this week end, i'm with my familly. I go back at home monday >> evening. I will review all your new branch and code tuesday evening. >> Don't forget that i'm in stop disease for few month due to my car >> crash and i will have a lots of free time to play with code (:=))) > > > ok - I'm in no hurry. The first of november(9 days ago) my daughter was born > and now I can always find how to spend time :) Congratulations (:-)))... Gilles Caulier _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Yuri,
I tested your code in your dedicated branch, and some point need to be changed : 1/ In "Target" settings view, you have inserted the option "Use external tools". It's not the right place. This option must go in "External Tools" settings view, on the top. Activating this option must enable all settings in this view, else these settings must be disabled. 2/ "External Tools" settings view is not the right name. Action performed by this view will be processed at end of queue. So for me the term is not enough explicit for end users. I'm sure that nobody will understand as well the purpose of this view. This is why it must be renamed, and some tips must be written in a label in this view to explain what's end users can do with it. 3/ "External View" will be used to call a program when all items for the queue are completed. The program, can be a binary or a script. In this view you force to use a script, by default as bash. And what's about Windows where Batch shell script are used. In other words, you need to write a GUI more universal where these information must be show : - the path to the Program - the name of the Program - the description of the Program - the arguments to pass to the Program. Here we don't care about the type of shell used, in case of a script. We don't care about the script content. Where you can show a script content, you cannot do it for a binary. Instead, propose to end users to be able to edit script with default editor set in KDE. This is not the goal to digiKam to host script source code. Because, if i'm not to wrong, scripts will be hosted as external file in home directory. Right ? 4/ In your GUI, i recommend to propose a list of Programs available and ready to use. User will assign one Program to the queue, and that all. The list can be stored in workflow XML file. Look how i do with workflow list view (workflow name + description are displayed)... Let's me hear if all my explanations are enough clear for you Best Gilles Caulier 2013/11/10 Gilles Caulier <[hidden email]>: > 2013/11/10 Yuri Samoilenko <[hidden email]>: >> Good evening >> >>> Yes, i see it. I'm registered to commit filter : >>> http://commitfilter.kde.org/ >>> Like this i see all commit done by all contributors through email. >> >> >> Nice stuff thx. >> >> >>> > What about branch manipulating strategy? >>> > 1. Is rebasing to master allowed in development branches? >>> >>> You can sync (you must) this branch with master changes to have your >>> branch updated in time. >> >> >> I mean that if I will use git rebase(not merge) to master then other >> developers who want to track my branch(I mean any development branch) can't >> fast-forward changes. They will forced to use 'force update', but rebased >> branch will have more plain(simple) commit history. In other word can I >> consider development branches as 'private'(allow rebase and breaking >> fast-forward) or it must be considered as 'public'(no rebase allowed only >> git merge). > > Public, because i will review your code and commit fixes... > >> >> >>> >>> No need if code changes are not too intrusive and quickly testable. In >>> general, making patch attached to relevant bugzilla entry is enough. I >>> don't like reviewboard. This require to manage too tools, where only >>> one is enough to control bug fixes : bugzilla. >>> >>> No need reviewboard (forget this tool) >> >> >> ok >> >> >>> For this week end, i'm with my familly. I go back at home monday >>> evening. I will review all your new branch and code tuesday evening. >>> Don't forget that i'm in stop disease for few month due to my car >>> crash and i will have a lots of free time to play with code (:=))) >> >> >> ok - I'm in no hurry. The first of november(9 days ago) my daughter was born >> and now I can always find how to spend time :) > > Congratulations (:-)))... > > Gilles Caulier Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Yuri,
What's the purpose of "Show in Context Menu" option ? Which menu is patched by your implementation ? Gilles Caulier 2013/11/16 Gilles Caulier <[hidden email]>: > Yuri, > > I tested your code in your dedicated branch, and some point need to be changed : > > 1/ In "Target" settings view, you have inserted the option "Use > external tools". It's not the right place. This option must go in > "External Tools" settings view, on the top. Activating this option > must enable all settings in this view, else these settings must be > disabled. > > 2/ "External Tools" settings view is not the right name. Action > performed by this view will be processed at end of queue. So for me > the term is not enough explicit for end users. I'm sure that nobody > will understand as well the purpose of this view. This is why it must > be renamed, and some tips must be written in a label in this view to > explain what's end users can do with it. > > 3/ "External View" will be used to call a program when all items for > the queue are completed. The program, can be a binary or a script. In > this view you force to use a script, by default as bash. And what's > about Windows where Batch shell script are used. In other words, you > need to write a GUI more universal where these information must be > show : > > - the path to the Program > - the name of the Program > - the description of the Program > - the arguments to pass to the Program. > > Here we don't care about the type of shell used, in case of a script. > We don't care about the script content. Where you can show a script > content, you cannot do it for a binary. Instead, propose to end users > to be able to edit script with default editor set in KDE. This is not > the goal to digiKam to host script source code. Because, if i'm not to > wrong, scripts will be hosted as external file in home directory. > Right ? > > 4/ In your GUI, i recommend to propose a list of Programs available > and ready to use. User will assign one Program to the queue, and that > all. The list can be stored in workflow XML file. Look how i do with > workflow list view (workflow name + description are displayed)... > > Let's me hear if all my explanations are enough clear for you > > Best > > Gilles Caulier > > > 2013/11/10 Gilles Caulier <[hidden email]>: >> 2013/11/10 Yuri Samoilenko <[hidden email]>: >>> Good evening >>> >>>> Yes, i see it. I'm registered to commit filter : >>>> http://commitfilter.kde.org/ >>>> Like this i see all commit done by all contributors through email. >>> >>> >>> Nice stuff thx. >>> >>> >>>> > What about branch manipulating strategy? >>>> > 1. Is rebasing to master allowed in development branches? >>>> >>>> You can sync (you must) this branch with master changes to have your >>>> branch updated in time. >>> >>> >>> I mean that if I will use git rebase(not merge) to master then other >>> developers who want to track my branch(I mean any development branch) can't >>> fast-forward changes. They will forced to use 'force update', but rebased >>> branch will have more plain(simple) commit history. In other word can I >>> consider development branches as 'private'(allow rebase and breaking >>> fast-forward) or it must be considered as 'public'(no rebase allowed only >>> git merge). >> >> Public, because i will review your code and commit fixes... >> >>> >>> >>>> >>>> No need if code changes are not too intrusive and quickly testable. In >>>> general, making patch attached to relevant bugzilla entry is enough. I >>>> don't like reviewboard. This require to manage too tools, where only >>>> one is enough to control bug fixes : bugzilla. >>>> >>>> No need reviewboard (forget this tool) >>> >>> >>> ok >>> >>> >>>> For this week end, i'm with my familly. I go back at home monday >>>> evening. I will review all your new branch and code tuesday evening. >>>> Don't forget that i'm in stop disease for few month due to my car >>>> crash and i will have a lots of free time to play with code (:=))) >>> >>> >>> ok - I'm in no hurry. The first of november(9 days ago) my daughter was born >>> and now I can always find how to spend time :) >> >> Congratulations (:-)))... >> >> Gilles Caulier Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Yuri,
"Show in Context Menu" option is a problem. I see that you have commited in your branch this feature for AlbumGUI context menu. I would to know how this feature work exactly... Also, if "External Tool" will be a common feature for BQM and contex menu, all settings cannot be hosted in BQM Queue settings. it's a non sence. digiKam Setup dialog is the right place for that. In this case a new section can be created in Setup, hosting all your current settings view from BQM queue settings section. In BQM, just a list of available "external tools" must be visible with the right one asssigned to the queue. Gilles Caulier 2013/11/16 Gilles Caulier <[hidden email]>: > Yuri, > > What's the purpose of "Show in Context Menu" option ? Which menu is > patched by your implementation ? > > Gilles Caulier > > 2013/11/16 Gilles Caulier <[hidden email]>: >> Yuri, >> >> I tested your code in your dedicated branch, and some point need to be changed : >> >> 1/ In "Target" settings view, you have inserted the option "Use >> external tools". It's not the right place. This option must go in >> "External Tools" settings view, on the top. Activating this option >> must enable all settings in this view, else these settings must be >> disabled. >> >> 2/ "External Tools" settings view is not the right name. Action >> performed by this view will be processed at end of queue. So for me >> the term is not enough explicit for end users. I'm sure that nobody >> will understand as well the purpose of this view. This is why it must >> be renamed, and some tips must be written in a label in this view to >> explain what's end users can do with it. >> >> 3/ "External View" will be used to call a program when all items for >> the queue are completed. The program, can be a binary or a script. In >> this view you force to use a script, by default as bash. And what's >> about Windows where Batch shell script are used. In other words, you >> need to write a GUI more universal where these information must be >> show : >> >> - the path to the Program >> - the name of the Program >> - the description of the Program >> - the arguments to pass to the Program. >> >> Here we don't care about the type of shell used, in case of a script. >> We don't care about the script content. Where you can show a script >> content, you cannot do it for a binary. Instead, propose to end users >> to be able to edit script with default editor set in KDE. This is not >> the goal to digiKam to host script source code. Because, if i'm not to >> wrong, scripts will be hosted as external file in home directory. >> Right ? >> >> 4/ In your GUI, i recommend to propose a list of Programs available >> and ready to use. User will assign one Program to the queue, and that >> all. The list can be stored in workflow XML file. Look how i do with >> workflow list view (workflow name + description are displayed)... >> >> Let's me hear if all my explanations are enough clear for you >> >> Best >> >> Gilles Caulier >> >> >> 2013/11/10 Gilles Caulier <[hidden email]>: >>> 2013/11/10 Yuri Samoilenko <[hidden email]>: >>>> Good evening >>>> >>>>> Yes, i see it. I'm registered to commit filter : >>>>> http://commitfilter.kde.org/ >>>>> Like this i see all commit done by all contributors through email. >>>> >>>> >>>> Nice stuff thx. >>>> >>>> >>>>> > What about branch manipulating strategy? >>>>> > 1. Is rebasing to master allowed in development branches? >>>>> >>>>> You can sync (you must) this branch with master changes to have your >>>>> branch updated in time. >>>> >>>> >>>> I mean that if I will use git rebase(not merge) to master then other >>>> developers who want to track my branch(I mean any development branch) can't >>>> fast-forward changes. They will forced to use 'force update', but rebased >>>> branch will have more plain(simple) commit history. In other word can I >>>> consider development branches as 'private'(allow rebase and breaking >>>> fast-forward) or it must be considered as 'public'(no rebase allowed only >>>> git merge). >>> >>> Public, because i will review your code and commit fixes... >>> >>>> >>>> >>>>> >>>>> No need if code changes are not too intrusive and quickly testable. In >>>>> general, making patch attached to relevant bugzilla entry is enough. I >>>>> don't like reviewboard. This require to manage too tools, where only >>>>> one is enough to control bug fixes : bugzilla. >>>>> >>>>> No need reviewboard (forget this tool) >>>> >>>> >>>> ok >>>> >>>> >>>>> For this week end, i'm with my familly. I go back at home monday >>>>> evening. I will review all your new branch and code tuesday evening. >>>>> Don't forget that i'm in stop disease for few month due to my car >>>>> crash and i will have a lots of free time to play with code (:=))) >>>> >>>> >>>> ok - I'm in no hurry. The first of november(9 days ago) my daughter was born >>>> and now I can always find how to spend time :) >>> >>> Congratulations (:-)))... >>> >>> Gilles Caulier Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Gilles Caulier-4
Hello.
2013/11/16 Gilles Caulier <[hidden email]> 1. ...This option must go in "External Tools" ... ok 2. "External Tools" settings view is not the right name. Action I will glad to rename 'external tools', but I have a trouble with new name... If I undestood right you suggested to rename it to "External View"?
When I selects the name I was inspired by Kate plugin "external tools", you can look at it in couple of first images:
3. ... The program, can be a binary or a script. In ok ... Because, if i'm not to Some times it is too complex to host very simple script outside of 'usage point'. I think when I implement previous feature we will return to this :) 4. In your GUI, i recommend to propose a list of Programs available and ready to use. User will assign one Program to the queue, and that I can't understand... GUI already have a combobox to select a name from available items...
>> What's the purpose of "Show in Context Menu" option ? Which menu is patched by your implementation ? The 'Edit' menu, near 'rename', and the DigikamImageView context menu, near 'rename'. I have done an ugly hack to get contexmenu updated from my GUI - I need help/explanation with right sollution.
I think 'Show in Context Menu' is good feature - user can create custom postprocessing action and assign in to shortcut(Ctrl+Alt+A to archive all selected files). _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |