Re: [Inkscape-devel] Re: Clone command

[bulia byak <archiver_1@ho...>]

>Yes that would make sense as default, but there should still be a key for 
>producing duplicates instead of clones (like when you want to copy a draft 
>that you want to change in different ways)

Yes.

>Is this behavior optional? I could think of many use cases where one only 
>wants the shape to be in sync, not the placement.

It's not optional in SVG, but we can try to work around that. I will look 
into it.

>But maybe a user could put the originals on a special layer that is locked 
>and invisible and thus have the same functionality?

That would prevent you from changing the original's shape too. SVG has no 
provisions for linking shape and not linking position.

_________________________________________________________________
Add photos to your e-mail with MSN Premium. Get 2 months FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

Re: [Inkscape-devel] Re: Clone command

[Helge Hielscher <hhielscher@un...>]

bulia byak wrote:
>> AFIAR Freehand is using Ctrl-C for clone and Ctrl-D for duplicate.
> 
> Ctrl+C does not Copy?!  They likely have not read HIG :)

maybe, it was Ctrl-Shift-C and Ctrl-Shift-D, I honestly do not remember, 
now I am using Inkscape instead and Freehand does not run in Linux/x86 
anyway 
(http://www.codeweavers.com/site/compatibility/browse/name?app_id=121)

>> BTW Is there a key for making a clone while moving an
>> object (duplicate works with space)? 
> 
> Not yet, but I thought about enabling space to leave clones, not 
> duplicates.

Yes that would make sense as default, but there should still be a key 
for producing duplicates instead of clones (like when you want to copy a 
draft that you want to change in different ways)

> [...] and second, clones 
> will be moved in sync with the original, and therefore the chain of 
> clones will behave almost like a stroke.

Is this behavior optional? I could think of many use cases where one 
only wants the shape to be in sync, not the placement. But maybe a user 
could put the originals on a special layer that is locked and invisible 
and thus have the same functionality?

> This is not easy to implement, 
> thoough, because currently clones may behave in a rather 
> counterintuitive (although perfectly standard-compliant) ways when the 
> clone is scaled/rotated and the original is then moved, or when both 
> original and clone are selected and moved together. I will try to 
> program special treatment for these situations so they behave more 
> intuitively.

Sounds good. But this is really not that easy.

Regards,
Helge

RE: [Inkscape-devel] Re: Clone command

[bulia byak <archiver_1@ho...>]

>AFIAR Freehand is using Ctrl-C for clone and Ctrl-D for duplicate.

Ctrl+C does not Copy?!  They likely have not read HIG :)

>Yes, that is very great. I was very disappointed when I found out that the
>only difference between Clone and Duplicate in Freehand is that
>Duplicate moves the duplicated object a bit and Clone does not (or vice
>versa).

The same was in Corel Draw. IMHO the "duplicate with a shift" is an example 
of an utterly redundant, "dumbed down" operation - I hope no one will ever 
come up with a suggestion to implement it in Inkscape :)

>BTW Is there a key for making a clone while moving an
>object (duplicate works with space)?

Not yet, but I thought about enabling space to leave clones, not duplicates. 
First, this will reduce the file size, and second, clones will be moved in 
sync with the original, and therefore the chain of clones will behave almost 
like a stroke. This is not easy to implement, thoough, because currently 
clones may behave in a rather counterintuitive (although perfectly 
standard-compliant) ways when the clone is scaled/rotated and the original 
is then moved, or when both original and clone are selected and moved 
together. I will try to program special treatment for these situations so 
they behave more intuitively.

_________________________________________________________________
MSN Premium helps eliminate e-mail viruses. Get 2 months FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

[Inkscape-devel] Re: Clone command

[Helge Hielscher <hhielscher@un...>]

On Thu, 22 Apr 2004 19:55:32 +0000, bulia byak wrote:
>>Do other vector graphics tools behave similarly or do they have Clone
>>tools?
>>The Gimp uses the single letter 'C' for Clone (dont know what Adobe
>>Photoshop uses) which seems reasonable.
> 
> Gimp and Photoshop are irrelevant - they are bitmap tools, and their
> "clones" are just copies that are not linked to the original.

AFIAR Freehand is using Ctrl-C for clone and Ctrl-D for duplicate.

> AFAIK no other vector editors have anything like our live clones. I did
> suggest this feature to Xara X guys a few years ago, but they told me it
> was too difficult to implement (obviously it did not fit their internal
> architecture). It's so deeply satisfying to be able to outperform them now
> with open source! :)

Yes, that is very great. I was very disappointed when I found out that the
only difference between Clone and Duplicate in Freehand is that
Duplicate moves the duplicated object a bit and Clone does not (or vice
versa).


BTW Is there a key for making a clone while moving an
object (duplicate works with space)?

Regards,
Helge

Re: [Inkscape-devel] non-recursive makefile: last chance for objections

[Kees Cook <inkscape@ou...>]

On Thu, Apr 22, 2004 at 11:31:55AM +1000, Peter Moulder wrote:
> On choice of name for src/blah/makefile: I deliberately wrote lower-case

BTW, when making changes or new areas where files will get auto-generated,
please add them to the .cvsignore file as well.  I've gone and done that for
.dirstamp and makefile in all the subdirectories.

Other than that, it looks great.  :)

-- 
Kees Cook                                            @outflux.net

Re: [Inkscape-devel] Clone command

[bulia byak <archiver_1@ho...>]

>I was going to comment on the shortcut too!
>
>Developers will probably want to reserve Ctrl+Shift+N for New Layer or New
>from Template, which is the kind of thing that shortcut is normally used
>for.

I changed that already, see my yesterday's mail.

>Adobe Illustrator doesn't seem to have anything directly analagous to a
>Clone tool.  The way it works in Adobe Illustrator seems to be that you
>make a symbol of something first and then you use the Symbol tools, namely
>the Symbol Sprayer which has the keybinding Shift+S.  I dont know how you
>plan to implement things in the future but you may want to reconsider the
>current design if it will inevitably need to be changed later.

Hmmm. It's not often (yet) that we beat AI on something, and now that we've 
done it, you suggest that we drop it for compatibility? :)

The Symbols facility and the Clone command are entirely different, even if 
they will use the same internal implementaion (via <use>). They have 
different goals and different uses. It would be nice for Inkscape to have a 
Symbols palette eventually, but even when we have it, Clone will remain too.

>Do other vector graphics tools behave similarly or do they have Clone
>tools?
>The Gimp uses the single letter 'C' for Clone (dont know what Adobe
>Photoshop uses) which seems reasonable.

Gimp and Photoshop are irrelevant - they are bitmap tools, and their 
"clones" are just copies that are not linked to the original.

AFAIK no other vector editors have anything like our live clones. I did 
suggest this feature to Xara X guys a few years ago, but they told me it was 
too difficult to implement (obviously it did not fit their internal 
architecture). It's so deeply satisfying to be able to outperform them now 
with open source! :)

_________________________________________________________________
Add photos to your e-mail with MSN Premium. Get 2 months FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

Re: [Inkscape-devel] Clone command

[Alan Horkan <horkana@ma...>]

On Mon, 19 Apr 2004, bulia byak wrote:

> Date: Mon, 19 Apr 2004 09:11:34 +0000
> From: bulia byak <archiver_1@...>
> To: jon@...
> Cc: inkscape-devel@...
> Subject: Re: [Inkscape-devel] Clone command
>
> >Bulia...this is an awesome feature. I wish the keyboard shortcut was
> >easier to do with one hand.

I was going to comment on the shortcut too!

Developers will probably want to reserve Ctrl+Shift+N for New Layer or New
from Template, which is the kind of thing that shortcut is normally used
for.  It would be very confusing for users to keep that shortcut given
that it is already strongly associated with certain actions in many other
applications and dekstops.

Adobe Illustrator doesn't seem to have anything directly analagous to a
Clone tool.  The way it works in Adobe Illustrator seems to be that you
make a symbol of something first and then you use the Symbol tools, namely
the Symbol Sprayer which has the keybinding Shift+S.  I dont know how you
plan to implement things in the future but you may want to reconsider the
current design if it will inevitably need to be changed later.

Do other vector graphics tools behave similarly or do they have Clone
tools?
The Gimp uses the single letter 'C' for Clone (dont know what Adobe
Photoshop uses) which seems reasonable.

For primary tools like this I think it is quite appropriate to use single
letter shortcuts (or possibly Shift+Letter).

> Most keys are already taken. Feel free to propose another shortcut.

hope my suggestions are of use, gotta go

Sincerely

Alan H.

Re: [Inkscape-devel] Clone commands + dialogs menu

[Artemio <theman@ar...>]

You rock!

Thanks so much for your great work!




Artemio.

-- 
KDEvibes ::: audio environment for KDE ::: http://kdevibes.artemio.net/
[local time 10:33:23 (GMT +3) 22 April 2004] [system uptime 6 min]

Re: [Inkscape-devel] Total remove of inkscape

[Lucas Vieites <lucas@as...>]

El jue, 22-04-2004 a las 07:27, Ted Gould escribi=F3:
> On Wed, 2004-04-21 at 10:12, Lucas Vieites wrote:
> >   On the other hand, is it safe to do this? I mean I think it wouldn't
> > compromise my box's stability
>=20
> If you installed from source probably the easiest way to do it is:
>=20
> make uninstall
>=20
> This will remove anything that 'make install' installed.
>=20

  I could hit myself with a hammer on the head. I've been working with
Linux for the last 4/5 years and I had never, ever heard of this option.

  Thank you, it worked fine for me.


--=20
Lucas 'Basurero' Vieites
<lucas@...>
Asix Inform=E1tica http://www.asixinformatica.com/
Tel/Fax: +34 986 54 26 98

[Inkscape-devel] Clone commands + dialogs menu

[bulia byak <archiver_1@ho...>]

Two new clone commands are added, and the shortcuts are changed to 
coordinate with Duplicate (Ctrl+D):

Alt+D            Clone
Shift+Alt+D   Unlink Clone
Shift+D         Select Original

Also, I eliminated the Dialogs menu moving its commands to other menus. It's 
more logical this way, with each dialog being close to other commands that 
deal with the same aspect of the program. The only misplaced command is the 
Text and Font dialog which is in Edit for now, but later a new Text menu 
will be added and it will move there.

_________________________________________________________________
Add photos to your messages with MSN Premium. Get 2 months FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

Re: [Inkscape-devel] non-recursive makefile: last chance for objections

[Bob Jamison <rjamison@li...>]

Heh!   No need to discuss, Peter!
I'm agreeing with you 100%.   ;-)
I think that this is a wonderful idea.
Good work.



Peter Moulder wrote:

>On Wed, Apr 21, 2004 at 09:47:44AM -0500, Bob Jamison wrote:
>  
>
>>Although we would lose the idea of having a set of libs,
>>    
>>
>
>Nothing changes about what .a libs we build (src/libnr/libnr.a etc.).
>
>  
>
>>For those who still want to have their lib buildable
>>and testable by itself [for unit testing]
>>    
>>
>
>The existing unit test framework remains.  (We may move some of utest.h
>to a .cpp file now that we can depend on things in other directories,
>and we can get rid of the check-recursive: all-recursive hack.)
>
>See also the discussion on convenience stub makefiles, elsewhere in this
>thread.
>
>Are these provisions already sufficient to address concern re
>unit-testing?
>
>pjrm.
>
>  
>

Re: [Inkscape-devel] Total remove of inkscape

[Ted Gould <ted@go...>]

On Wed, 2004-04-21 at 10:12, Lucas Vieites wrote:
>   On the other hand, is it safe to do this? I mean I think it wouldn't
> compromise my box's stability

If you installed from source probably the easiest way to do it is:

make uninstall

This will remove anything that 'make install' installed.

		--Ted

Re: [Inkscape-devel] non-recursive makefile: last chance for objections

[Peter Moulder <Peter.Moulder@in...>]

On Thu, Apr 22, 2004 at 12:32:24AM +1000, Peter Moulder wrote:

> Advantages:
> 
>   + Can depend on things from other directories.  E.g. some files in
>     display/ depend on helper/sp-marshal.h having been built, and various
>     */*-test programs depend on libraries in other directories (previously
>     hacked with a `check-recursive: all-recursive' dependency in
>     src/Makefile.am).
> 
>   + Compilation is expected to be faster:
> 
>       - Fewer invocations of automake and make.
> 
>       - Better parallelization is possible with make -j / make -l (e.g.
> 	when using distcc).
> 
>     However, making CPPFLAGS per-target means much longer generated
>     Makefile content.  I haven't yet done timing tests (underway).
> 
> Disadvantages:
> 
>   + All files mentioned in the makefile fragments need to specify their
>     directory.  E.g. if blah/Makefile.am used to contain
>     
>       libblah_a_SOURCES = \
>       	foo.cpp foo.h
> 
>     then blah/Makefile_insert will now contain
> 
>       blah_libblah_a_SOURCES =	\
>       	blah/foo.cpp	\
> 	blah/foo.h

    + Only partial support for typing `make whatever' from inside
      src/blah/ directories.

    + Small amount of extra clutter: an extra makefile per subdirectory
      of src (or lose all support for `make whatever' from inside
      subdirectories of src); and src has both Makefile.am and
      Makefile_insert.

    + Makefile_insert scheme will be unfamiliar to most new developers.

    + Easier to have problems due to variables in one Makefile_insert
      having an effect on other parts.  automake detects the most common
      errors (two variables with the same name).

    + Looks like we'll want to remove support for automake1.6 if we go
      to non-recursive makefiles.  However, automake1.7 has been around
      since about 2002-09-25, and automake1.8 is already available.

      (Problems with automake1.6: problem if we have two .cpp files of
      same name in different directories.  Appears not to handle
      blah_libblah_a_CPPFLAGS properly.)

Any other advantages/disadvantages?

> Checks to be done before switching:
> 
>   + `make install' creates same directory tree.
>     
>     - Done.  Some differences in the inkscape/inkview executable files,
>       all other files bytewise-identical.
>  
>   + `make check' works.
> 
>     - Done.  Works.  Hmm, haven't checked that all expected checks are
>       getting run.
> 
>   + `make check' works immediately after `make clean'.
> 
>     - Not yet checked.
> 
>   + `make distcheck' works.
> 
>     - Not yet checked.

    + Test with automake1.7, 1.8.  Probably just testing `make && make
      check'.

      - automake1.6 seems not to work well enough (see above).

    + Check that warnings/errors are parsed ok by xemacs21.  (Other
      editors are likely to be ok iff xemacs21 has no problem.)
      
    + Try gdb, to check that it has no problem with filenames.

Any other checks to be done?

pjrm.

[Inkscape-devel] deprecation warnings

[MenTaLguY <mental@ry...>]

I've deprecated much of the old sp_selection() API; all that remains are
tiny inline wrappers that are adaptors for the new API.

If the deprecation warnings bother you -- just replace those inline
wrappers with their contents at their call sites.

e.g. sp_selection_empty(sel) becomes sel->clear()

-mental

Re: [Inkscape-devel] non-recursive makefile: last chance for objections

[Peter Moulder <Peter.Moulder@in...>]

On Wed, Apr 21, 2004 at 09:47:44AM -0500, Bob Jamison wrote:
> Although we would lose the idea of having a set of libs,

Nothing changes about what .a libs we build (src/libnr/libnr.a etc.).

> For those who still want to have their lib buildable
> and testable by itself [for unit testing]

The existing unit test framework remains.  (We may move some of utest.h
to a .cpp file now that we can depend on things in other directories,
and we can get rid of the check-recursive: all-recursive hack.)

See also the discussion on convenience stub makefiles, elsewhere in this
thread.

Are these provisions already sufficient to address concern re
unit-testing?

pjrm.

Re: [Inkscape-devel] non-recursive makefile: last chance for objections

[Peter Moulder <Peter.Moulder@in...>]

On Wed, Apr 21, 2004 at 01:18:11PM -0400, MenTaLguY wrote:
> On Wed, 2004-04-21 at 10:32, Peter Moulder wrote:
> > Any other advantages/disadvantages?
> 
> Hmm, is there any way to (easily) construct stub makefiles so that it
> isn't necessary to cd up a couple levels before you can run 'make'?

Yes and no.  src/blah/makefile can be of the form:

  # Explicit so that it's the default rule.
  all:
  	cd .. && $(MAKE) blah/all

  %:
  	cd .. && $(MAKE) blah/$@

  .PHONY: all

I've already inserted a blah/all rule into src/blah/Makefile_insert for
all blah.  This works for `all' and for all real files (libblah.a), but
`clean' may be trickier, due to different placement of object files
(src/blah_libblah_a-foo.o instead of src/blah/foo.o).  Maybe can be
approximated with `rm -f $(blah_libblah_a_OBJECTS) blah/libblah.a' or
`rm -f blah_libblah_a* blah/libblah.a'.  For the purposes of deciding
whether to go ahead with this change, let's conservatively assume that
we don't succeed in implementing `clean': if ppl consider this a
show-stopper then I'll see what I can implement before deciding on
whether to switch.  Similarly let me know if there are other rules that
people consider important in this stub makefile.

On choice of name for src/blah/makefile: I deliberately wrote lower-case
to facilitate tab completion.  I'm currently considering not having them
generated by configure, though that means requiring something like gnu
make: e.g. it requires that $(MAKE) be defined, and it's desirable that
`%' is understood.  Explicitly setting the value of MAKE seems to
destroy its special meaning.  These stub makefiles are only for
convenience, and are principally intended for developers, so I don't
think it a problem for them not to be as portable as the generated
src/Makefile.  Variations:

   - Have them generated by configure, which detects whether or not
     explicit MAKE = ... is required (`@SET_MAKE@').  The only
     disadvantages are having a few makefile.in files around and a bit
     of extra work & output from configure/config.status.

   - Name them GNUmakefile so that non-gnu make programs don't even see
     the makefile.  Avoids the possibility of a confusing error message
     if MAKE isn't defined (in which case that make will try to execute
     blah/something).

   - Explicitly set `MAKE = make' in the makefile.  The magic value of
     $(MAKE) in gnu make would be lost.  May interfere with things like
     `make -n' working (I haven't tried).

pjrm.