patch etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
patch etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

12 Temmuz 2016 Salı

.docx ve .odt nedir ?

 

   

 

.docx nedir?


 docx, Microsoft‘un Windows işletim sistemleri içerisinde yer verdiği Word yazılımının yeni nesil dosya uzantısıdır. Microsoft Word 2007 sürümüne kadar Word dosyalarının uzantıları “.doc” şeklinde kayıt edilirken Word’ün 2007 sürümü ve sonrasında kullanılan Word sürümlerinde dosya formatı “.docx” olarak oluşturulmaktadır.

 Belge verilerini tek bir binary dosyasında depolayan .doc dosyalarının aksine, .docx dosyaları Open XML formatı kullanarak oluşturulur, bu format da belgeleri sıkıştırılmış bir zip paketinde ayrı dosyalar ve klasörler olarak depolar.

 Bir .docx dosyasının içinde XML dosyaları ve üç klasör bulunur (docProps , word , ve _rels). Bu klasörler, belge özelliklerini, içeriğini ve dosyalar arasındaki ilişkileri tutar. Bu yapı, belgenin içeriğinin daha fazla erişilebilir olması için tasarlanmıştır.



 DOCX dosyasını açmak için bilgisayarınızda Microsoft Word 2007 veya daha sonraki sürümlerinin bulunması gerekiyor. Eğer bu sürümlerden daha önce yayınlanmış bir Word sürümü kullanıyorsanız DOCX dosyalarını açabilmek ve oluşturabilmek için Microsoft tarafından yayınlanmış olan uyumluluk paketini kurmanız gerekiyor.

 LibreOffice ve OpenOffice başta olmak üzere diğer ofis yazılımlarıyla veya DocX Viewer benzeri yazılımlarla da docx dosyalarını açabilirsiniz.




  .odt nedir? (Open Document Text)


 odt, LibreOffice Writer ve Google Belgeler gibi kelime işlem uygulamaları tarafından kullanılan dosya uzantısıdır.

 OpenDocument ya da tam adıyla OASIS OpenDocument XML biçimi, sayısal ortamda metin, hesap tablosu, çizim ve sunu gibi belgelerinizi saklamaya yarayan bir açık ve özgür belge standardıdır.

 İlk sürümü 3 Mayıs 2006 tarihinde kabul edilen OpenDocument biçimi, çok sayıda kelime işlemci ve ofis yazılımı tarafından desteklenmektedir. Bu belge biçimi LibreOffice, Apache OpenOffice, Calligra, Google Dokümanlar arayüzü, StarOffice ve Lotus Notes ürünleri tarafından da kullanılmaktadır.

 OpenOffice.org 2.0'dan itibaren tüm OpenOffice.org bileşenleri (Writer, Calc, Impress, vb) standart OASIS OpenDocument XML biçimini kullanmaya başladı. Bu sayede üreticiden bağımsız bir şekilde hazırlanan belgeler, herhangi bir editör yardımıyla açılıp incelenebilmektedir.

  Aslında birer XML belgeleri olan OpenDocument dosyaları, kayıpsız ZIP sıkıştırma algoritmasını desteklemektedir. Bir .odt dosyasının içinde XML dosyaları, diğer dosyalar(mimetype) ve iki dizin bulunur (META-INF, Thumbnails).


 *content.xml
   En önemli dosyadır. Belgenin gerçek içeriğini taşır. Temel HTML biçiminde esinlenilmiştir. İçeriği şöyledir:



*styles.xml
  Stil bilgilerini içerir. OpenDocument, biçimlendirme ve düzen için stilleri yoğun kullanır. Stillerin türleri vardır.
  • Paragraph styles
  • Page styles
  • Character styles
  • Frame styles
  • List styles

*meta.xml
    metadata dosya verilerini içerir. Örneğin; Author, "Last modified by", date of last modification. <dc:...> tagının ismi Dublin Core XML standarttan gelir. İçeriği şuna benzer:


*settings.xml
  Yakınlaştırma faktörü ve imleç konumu gibi ayarları içerir. Bunlar içerik veya düzen olmayan özelliklerdir. 

*mimetype (file)
  Belgenin tek satırlık dosyasıdır. Aslında bu dosya uzantısı biçiminin önemsiz olduğunun bir göstergesidir.. Dosya uzantısı orada sadece kullanıcı yararına bulunur.

*Thumbnails (directory)
  Küçük resim için ayrı bir dizindir. Küçük resmin, “thumbnail.png” olarak kaydedilmiş olması gerekir. Dosya kaydedildiğinde, belgenin küçük resim gösterimi varsayılan olarak oluşturulur.

  Belgenin temsili ilk sayfa, ilk tablo vs. olmalıdır. Küçük resimler için gerekli büyüklük 128x128 pixel'dir. Thumbnail Managing Standard (TMS) ına uygunluk sağlamak amacıyla, küçük resmin 8bit olarak kaydedilmiş olması gerekir.

*META-INF (directory)
  OpenDocument pakette yer alan dosyalar hakkında "manifest" adında bir XML dosyası saklanır. Manifest dosyası her zaman "META-INF/manifest.xml" yol adında depolanır. Manifestte saklanan bilgilerin ana parçaları:
  • Paketin içindeki tüm dosyaların bir listesi
  • Paketteki her dosyanın media tipi
  • Eğer paketin içinde saklanan bir dosya şifreli ise, dosyanın şifresini çözmek için gerekli bilgileri saklanır.

*Pictures (directory)
  Belgedeki görüntüler için ayrı bir dizin vardır. Bu dizin OpenDocument belirtimi içinde tanımlı değildir. Bu dizindeki eklenen dosyanın formatına göre, görüntü biçimlerini kullanabilirsiniz. Görüntü verileri rasgele bir biçime sahip olmakla birlikte, SVG ve PNG formatında saklanması tavsiye edilir.
  
 

15 Haziran 2016 Çarşamba

Linux Kernel İçin Yama Hazırlamak




Merhabalar, 

Geçen yıl, henüz 2.sınıftayken Linux Kernel için yamalar hazırladığım bir dönem olmuştu fakat bununla ilgili blog yazmayı atladığımı farkettim ve Türkçe kaynaklarında yetersiz olması sebebiyle kolları sıvadım :)

OPW isimli Gnome'un kadınlar için düzenlediği bir etkinlik var. Yılda iki defa düzenleniyor. Etkinliğin birçok katılımcısı bulunuyor (Linux Kernel, Gnome, Debian, Fedora, Mozilla gibi). Bende o dönemde Linux Kernel projeleri için hazırlandım. 

Linux Kernel projelerinden birine başvurmadan önce çekirdeğe yamalar yollamanız ve öngörülen sayıda yamalarınızın kabul edilmesi gerekiyor.
Opw Kernel sayfasında tüm yapılması gerekenler, okumak için önerilen birkaç kitap var. Burada da Greg Kroah-Hartman ilk yamanın nasıl yapılacağından bahsetmiş. 


Çok fazla kişinin sürekli aynı dosyalar üzerinde değişiklik yapıyor olması durumunda da daha gelişmiş bir biçimde sürüm takip sistemi kullanmam gerekti.
Git uzaktan birlikte çalışmak için oldukça yetenekli bir araç. Bu süreçte zaten bildiğim temel git kullanımının yanında, git'in daha fazla özelliğini kullanmam gerekti.


Temel olarak yama göndermeye kernel.org'dan aldığım çekirdek kodları dizini içerisindeki drivers/staging'den başladım. Çok temel kodlama biçimi düzeltmeleri yapabileceğimiz gibi, daha karmaşık düzeltmeler de yapabiliriz. 

Çalışmaya ilk başladığımda checkpatch.pl, sparse ve coccinelle araçlarını kullanmayı öğrendim. Bunlar statik ve en temel araçlardır. Başlangıç olarak Linux Kernel'a kodlama biçimi düzeltme dışında Sparse ve Coccinelle araçlarını kullanarak katkı verebiliriz. Bu araçlarla drivers/staging altındaki kodları derlediğimizde aldığımız uyarı mesajlarına göre düzeltmeler yapabiliriz.

Sparse aracı ile fonksiyon tiplerinin ya da değişken tiplerinin doğruluğu, gereksiz fonksiyonları kaldırma, tip dönüşüm işlemlerinin doğruluğu gibi uyarıları analiz edebiliriz.

Coccinelle, otomatik olarak analiz yapan ve C kodunu yeniden yazabilen bir araçtır. Kendine özel Smpl (Semantic Patch Languange) ile yazılan anlamsal betiklerden oluşmaktadır. Asıl yararı aynı düzeltmeleri her dosya için tek tek yapmak yerine, bir şablon oluşturup onunla birçok dosyayı tek seferde tarayayıp değiştirebilmesidir.

Yama gönderirken zorlandığım yanlardan birisi de, Linux Kernel ekibi kodlama biçimine oldukça önem veriyor. Bu yüzden aynı yamayı defalarca yeniden sürümlediğim zamanlar oldu. Hatta kodlama biçimini test etmek için yazdıkları bir Perl betiği de var. (Kodlama biçimi düzeltme yamalarını gönderebilmek için bu betiği kullanmalıyız.) 

Hazırlandığım süre boyunca git kullanımı, çekirdek ve derleme hakkında çok şey öğrendim. Teknik bilgiler dışında asıl kazandığım büyük deneyimin, uzaktan yabancı birileri ile çalışmak olduğunu düşünüyorum. 

Yazının geri kalanında bu işin biraz teknik kısmından bahsedeceğim.


Kernel'ı Derleme 

$ sudo apt-get install vim libncurses5-dev gcc make git exuberant-
ctags


$ mkdir -p git/kernels; cd git/kernels

$ git clone -b staging-next
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git


$ cp /boot/config-`uname -r`* .config

$ make -jX

$ sudo make modules_install install

* Bu adımlardan sonra bir takım grub ayarlarını yapmamız gerekiyor.

$ sudo vim /etc/default/grub komutu ile dosya içeriğini açarak, gerekli düzenlemeyi yapıyoruz.
   
  GRUB_HIDDEN_TIMEOUT=0
  GRUB_HIDDEN_TIMEOUT_QUIET=true
  GRUB_TIMEOUT=10 
 
Düzenleme işlemi bitince çalıştırmamız gereken komut ise: 

$ sudo update-grub2

E-mail Ayarları

Linux kernel için yama göndermek istiyorsak, bazı e-mail ayarlarını düzenlemeye ihtiyacımız var.

$ sudo apt-get install git-email

$ vim .gitconfig 


[user]
   name = Your Name
   email = your.email@example.com 

Git ile Yama Hazırlarken Kullandığım Temel Komutlar

$ git add . 

$ git commit -m “İlk commit”

$ git branch -a

$ git checkout -b ilk-yama

İlk Yamayı Göndermek 

$ git diff

$ git add <degisiklik_yapilan_dosya>

$ git commit -s -v 

$ git send-email --annotate HEAD^

Sonraki Yamalar İçin

 *Depo Güncelleme:
     
      $ git fetch staging
      $ git checkout -b staging-fixes-rebase
      $ git rebase staging/staging-next
  
 *Versiyonlama:

      $ git format-patch –subject-prefix="PATCHv2"

  *Eski commitleri görüntülemek
      
      $ git log

 *Commitleri Birleştirmek:
    
     $ git rebase -i commit_id

Sonraki yazımda görüşmek üzere :) 
     
   

3 Mayıs 2016 Salı

LibreOffice Hackfest Ankara 2016



Merhabalar,

Çanakkale'deki LibreOffice için yürütülen çalışmalar geliştirici ekibin de dikkatini çekti ve onların önerisiyle 30 Nisan - 1 Mayıs 2016 tarihlerinde Ankara'da ULAKBİM'in ev sahipliğinde bir hackfest düzenlendi. Etkinliğin iletişim dili İngilizceydi. Etkinliğe katılan LibreOffice geliştiricileri Michael Meeks, Marcus Mohrhard ve Jan-Marek Glogowski oldu.

Etkinlikte ilk gün geliştiricilerin sunumlarını dinledim. LibreOffice kod tabanı, Core class'larının yapısı, problemleri çözme, real world engineering gibi mevcut çalışmalarıma hız kazandıracak konular anlatıldı. Geliştirmede kullanılan araçlardan bahsedildi. Debug denemeleri yaptık.




Sonraki gün ise kodlama yapmaya başladım. Kritik noktaları danışabileceğim geliştiricilerin hemen yanımda olması gün boyunca 5 yama göndermemi sağladı :) Oraya gitmeden önce çalıştığım bug üzerinde işlerimi hızlandıracak yeni bir yol öğrendim. Bunun dışında Michael Meeks yapabileceğimi düşündüğü bir iş önerdi. Hemen üzerinde çalışmaya başladım. Bu işin şimdiye kadar verdiğim katkılardan biraz daha zor olduğunu ama benim üstesinden geleceğimi söyledi. Yakın zamanda bununla ilgili güzel haberler vermek isterim size \o/ . 



İyiki katıldım diyebildiğim çalışmalardan biri oldu. Bu geliştiricilerle çalışma fırsatını yakalayabilmem süperdi. Çok yoğun ve oldukça eğlendiğim bir  etkinlikti. Ayrıca Akademik Bilişim'de Atölyeden tanıdığım arkadaşları da görmek harikaydı. Başta +Necdet hocama, etkinliğe ev sahipliği yapan TÜBİTAK-ULAKBİM'e ve Muhammet Kara, Gökhan Gurbetoğlu'na, çok uzaklardan gelen Michael Meeks, Marcus Mohrhard ve Jan-Marek Glogowski'ye çok teşekkür ederim. 

Etkinlikte bir de badge kazanmışım, onu da şuraya bırakıyorum :)




3 Kasım 2015 Salı

Libreoffice Çalışmalarım



Merhabalar, bu sene okul başladığından beri Libreoffice ile ilgili çalışmalar yapıyorum. En son yazımda ilk kod katkımı verdiğimden bahsetmiştim. Yaptığım katkıdan çok, bu süreç önemliydi benim için. Bu aşamada kendinizi bu iş için yetersiz hissetmemeniz çok önemli. Başlangıçta yapabileceğiniz katkı için bug'lar seviyelendirilmiş zaten. Örneğin gereksiz yorum satırlarını silmek gibi işlerde var. Süreç boyunca bir çok şey öğreniyorsunuz zaten. Önemli olan şey İngilizce bilmek, çünkü geliştirici sayfası İngilizce.

Bu süreç nasıl ilerliyor?

Geliştirici wiki sayfası sizi yönlendiriyor aslında. Libreoffice kodunu indiriyor ve derliyorsunuz (şurada bahsetmiştim bu işten).  Kendinize uygun bir bug bulduktan sonra, git ile yamanızı hazırlayıp gönderiyorsunuz.(LibreOffice geliştiricileri çok anlayışlı ve yardım sever, pek çok konuda IRC 'de yardım alabilmek mümkün.) Her yollanan yamanın Jenkins ile 3 platformda çalışabilirliği kontrol ediliyor. (Linux, MacOS ve Windows). Tüm platformlarda başarı ile derlenebiliyorsa yamaya geliştiricilerde bakıyor. Uygun bulursa kodu onaylıyor ve sizin adınıza ekliyor. Bunun için öncesinde bir de lisans metni yolluyorsunuz.

Ne durumdayım ? 

Başlangıç seviye bir yamam onaylandıktan sonra, başka bir bug ile ilgilendim. Burada uno bileşeni uygulamaları için yapıcı işlevlerinin başlatılmasının uzun bir süreç olduğundan bahsediliyordu. Bu süreç için yeni bir yol önerilmişti. Bu süreci kolaylaştıracak ve biraz daha hızlı yapacaktı. Üzerinde çalışmak için kendime bir bileşen seçtim ve bunun yapıcı işlevinde değişiklikler yaptım ve yamamı yolladım. Bir gün önce yamam alındı. Şimdi daha güzel işler yapabilmek için çalışıyorum.


4 Ekim 2015 Pazar

LibreOffice Paketi İçin Yama Hazırlamak



LibreOffice özgür ofis yazılımı Dünya'nın dört bir yanından katkıcıların ortak emekleri ile geliştiriliyor. Eğer bir geliştiriciyseniz, hata düzeltme ve yama gönderme işlerinde de katkı verebiliyorsunuz. Bende bu iş için gönüllü oldum ve yama hazırladım. Ben ubuntu 14.04 LTS kullandım. Bu yamayı hazırlarken yaşadığım süreçten biraz bahsedeyim istiyorum.

Başlangıçta Libreoffice'i kaynak kodundan derlemeniz gerek. Bunun için önce ihtiyacımız olan bağımlı paketleri kuralım.

$ sudo apt-get build-dep libreoffice

Depoyu yerelimize clone edelim.

$ git clone git://anongit.freedesktop.org/libreoffice/core libreoffice

Proje dizinine geçelim.

$ cd libreoffice 

Hatasız çalıştığını kontrol edelim ve derleyelim.

$ ./autogen.sh 

$ make
Derleme işleminin ardından writer'ı çalıştırıp, projenin düzgün çalıştığından emin olalım.

$ instdir/program/soffice --writer 


Yama yollarken gerrit aracı da kullanılıyor. İlk kez yama yollayacaksanız şuraya kendinizi eklemeniz gerekiyor. Bu işlem için libreoffice@lists.freedesktop.org adresine, mail başlığı: <your name> license statement , mail içeriği ise 
"All of my past & future contributions to LibreOffice may be licensed under the MPLv2/LGPLv3+ dual license." olan bir mail gönderiyoruz.

Gerrit kullanabilmek için ilk adımda şu komutu çalıştırıyoruz.

$ ./logerrit setup

Çalıştırdıktan sonra "/home/[username]/.ssh/id_rsa.pub" içeriğinin tamamını Gerrit üyeliğimizde settings sekmesinden Ssh Public Keys kısmına ekliyoruz.( Gerrit üyelik işlemini openid ile yapmak mümkün, ben bunun için ubuntu one hesabımı kullandım.)

Test işlemi sorunsuz tamamlanırsa artık Gerrit aracını kullanabiliyoruz.

$ ./logerrit test

Şimdi yeni bir dal oluşturalım.

$ git checkout -b <yeni dal adı> 

Şuradan bug'ları inceleyip istediğimizi kendimize assign edelim. Ardından kaynak koddan çözüm için gerekli değişiklikleri yapalım. Değişikliği bitirdiğimizde;

$ git add <dosyaismi>

$ git commit -m "commitin içeriğini anlatan mesajımız"

Bu commiti Gerrit'e de yollayalım.

$ ./logerrit submit master

Belki ilgilenen olursa diye şurada kabul edilen yamam da bulunmakta. Ayrıca yolladığınız commitleri gerrit sayfasından görmekte mümkün. Daha ayrıntılı bilgiye şuradan ulaşabilirsiniz.